Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 6 years ago.
Improve this question
I'm looking for some help and it goes like this:
I'm a fairly green software developer, and focus mainly on the web (python/PHP) but am pretty well experienced with Java applications and as an electrical engineering student, looking forward to dive into some c/c++. I've pretty much grown up on Windows machine, but hate .net with a passion and dont really have a need to develop on Windows - besides the fact that i'm used to it.
I'm looking to switch to Ubuntu as my development machine entirely (without having WinXP on another partition) as I'm quite fedup with Windows, but am tempted to go back to it everytime i'm stuck with countless driver issues (be it headphone drivers, or dual monitor setup, etc). I'm looking for a comprehensive resource that will help this transition and doesn't assume you know alien linux shell keywords.
Cheers.
In my personal experience with Ubuntu, the two places that I consistently found help were Ubuntu Forums and Ubuntu Wiki. These two sites demonstrate just how helpful, organized, and motivated the Ubuntu Community is.
An additional resource is also the Ubuntu channel on IRC. Whenever I was stuck with an issue that I felt warranted a discussion with someone (or a handful of people), IRC was always a good place to go.
Lastly, I tend to learn a lot from reading blogs from people that are heavily involved in Ubuntu's development. Planet Ubuntu is a pretty good feed to keep in your reader. It's essentially an aggregation of a number of blogs. The majority of the posts are related to Ubuntu; however, there are occasional posts that are just about the developer's thoughts and opinions.
I would recommend you set up your PC in such a way that:
Have three partitions, one for swap (1-2x ram size), one for / (root dir) and one for /home.
Keep everything not related to running linux in /home, or on completely separate harddrives. Don't store stuff you wanna keep on the partition that holds /.
This allows you to rather effectively nuke your entire linux install and install another one without losing your data or your settings. This lets you do two things:
If you really break your install you can often just nuke it and reinstall. Most distros you're going to try will deal with upgrading you back to the current version quickly.
If you're not happy with, say, Ubuntu, you can just nuke it and install something else, say OpenSUSE, CentOS or Fedora.
The key thing to remember is that all your personal settings (desktop background, application settings etc) are stored in /home/yourname/ under hidden directories, definied by naming them with a '.', .gnome for example. System settings are stored in /etc, but with most distros these days system settings are so well guessed you never need to care. The data you care is under /home/yourname.
If you're going to move to another distro I would recommend copying those hidden directories into another directory under your home/yourname directory, say 'old-prefs' or something. This is because you want to start 'fresh' with the new install. You can copy back hidden dirs you know you want later (I for example would always copy back .opera, .mozilla).
Also, don't throw away your Windows install, not yet anyway. You may find Linux is not for you. You may find the inability to play any new games without rebooting a pain. You may find various things don't work as seemlessly as they do on Windows, in my experience that includes Adobe Flash and various sound-related things (sound has recently been rooted imo due to early PulseAudio adoption).
As other people have said, the Ubuntu wiki and Ubuntu forums are good, and for that reason it's the first distro I suggest you try. It's so popular that you often get better results in google by replacing 'linux' with 'ubuntu'.
Not an answer, per se, but some unsolicited advice:
All platforms have problems
Developing on one platform is pretty much like developing on another
Familiarity with both the *nix and Windows worlds is useful
Good luck!
I would agree with Tom's answer in terms of resources to answer questions. In addition to that, I would recommend being prepared to learn to use a command prompt and to learn a lot more about the underpinnings of the system than you are probably used to on Windows. Linux in general exposes the "machinery" of the OS quite a bit more frequently than Windows, and if you're the type of person that doesn't like to tinker with things occasionally then it is probably not for you.
For example, my dad is an engineer and experienced programmer, and he has no interest in using Linux, because he doesn't want to have to futz with things to get them working. For him, using Windows is all about the path of least resistance. I on the other hand, use OS X and Linux on a regular basis and I love that when things don't work, I at least have the option of digging in and fixing the problem. I love the ready availability of command line interfaces, multitude of scripting options, and the general openness Linux has. It's hard to tell from your post which type of personality you have, but if you're looking forward to digging into C/C++ and you enjoy electrical engineering, Linux will probably be a good fit for you.
Lastly, I highly recommend using the command prompt frequently, even when there are GUI interfaces. Linux GUI apps are frequently built on top of the console applications. It almost always will be easier to work with things if you're familiar with and comfortable with the command line. Most seasoned *nix users also find that eventually it becomes more efficient and comfortable to get many types of tasks done from a command prompt. If you plan to develop on Linux then this is all the more likely to occur as you get used to thinks like working with build tools and scripts that are common on UNIX platforms.
EDIT: One last thing I cannot recommend enough: use virtualization! Install something like VirtualBox, VirtualPC or VMWare Player to run Linux in a virtual environment. Virtualization has come along far enough since the days I started using Linux such that you can now install and run Linux in a full-screen environment almost indistinguishable from running it natively. Using a virtualized environemtn also will make things like drivers a non-issue, since the generic "hardware" should be supported out of the box. Virtualization or a "Live CD" version of Linux (such as the Ubuntu live CD) is a fantastic way to get used to Linux without having to throw out the safety blanket of Windows right away.
The other advice here is excellent. As somebody who made the same leap at the end of 2005, I just wanted to add my own two penneth.
Expect a steep learning curve. I'd been using Unix / Linux type servers for best part of 13 years when I switched. Not the same. When I switched is when I started learning. My productivity dipped at first, but I know SO much more about our deployment environment now - and of course productivity back an exceeded original. But it 'aint easy.
When you DO switch, you never look at an OS in the same way again. Makes it easy treating any OS as just a set of things you have to learn. This in itself is a good thing (tm)
The biggest problem at first is looking for linux equivalents of windows ways of doing things. I remember looking for decent FTP client (in the end IF I am forced to use FTP now, I use konqueror with two windows - but just wait till you discover rsync!), a decent graphical subversion client (then realised that knowing how to use find, sed, grep and svn cmd line client was much much better) etc.
I have heard people before say that resorting to the command line is admission of failure. While this may be true if there is no choice in it, you soon come to revel the blending of graphical and command line tools to get the job done. For example, I tend to use find and grep and xargs to load up my IDE with stuff I want to work on.
You learn to love computing again. The whole computer becomes a tool for getting things done.
The biggest change is the freedom. Not the cost. But that fact that installing software is as simple as "sudo apt-get install" or graphical equivalent. Even a very non-technical windows user soon comes to relish this amazing aspect that of Linux.
Enjoy!
Related
I'm probably missing something, because I don't hear anyone else mentioning this. But when I look at the process and file system modules I see a lot of Unix-isms that are unlikely to work on Windows. How is this going to work for Windows users? Windows users who never used Unix may not even realize which are Unix-isms, that are never going to work for them. I suppose this is really just a documentation issue, it would be nice to filter documentation based on Unix or Windows. Process.getuid() would be one example. Chmod would be another. Even SIGUSERn is there. (Vague memories of servers mysteriously shutting down.) I do have Unix experience from way back, but many will not have. I avoided Rails because it was slow on Windows, but I hear that node.js is smoking fast on Windows, so I'm hopeful!
Since version v0.6 (except the latest v0.6.9, big fs bug), Node.js has become a first class citizen on Windows. Because of this, it's my thought that most 3rd party modules will eventually support Windows. A lot of the major ones do now, Express.js most notably.
This will get better too. Some third party modules require the extra step of forcing the user to compile native C++ modules (NPM/node-waf automates this). However, in future versions Node.js will be ditching this for binary compatibility. The developers behind Node.js are trying very hard to emphasize a first class development experience that focuses on a pleasant developer experience across all platforms.
Admittedly, the Node.js experience will be better on OS X or Linux, but it's going to only get better on Windows. I highly encourage you to check it out if you haven't already.
Say I find a Windows developer with 10+ years of experience, great skills in C/C++ and excellent references as a versatile coder who gets things done. Can I hire him for development on the Linux platform and expect him to be efficient in production within a couple of weeks? Or is the threshold too high when speaking in terms of development environment and all the common tools used in daily work? What are the main obstacles for this person to overcome?
Note, this is a general question, where I basically assume typical Windows and Linux environments (Visual Studio vs. Eclipse or EMACS, Add/Remove programs vs. apt-get, dialog wizards vs. commandline, and so on)
It really depends on a lot of factors.
A really good developer will be able to learn everything they need to know fairly quickly. The main language is the same.
However, depending on what you're developing on Linux, there may be some major learning curves to overcome.
A couple of examples:
The entire operating system APIs are different.
If you're using any large libraries, there will be a learning curve to the library.
If you're using more traditional unix build systems, there will (possibly) be a learning curve to using those vs. the normal "Windows way" of working in an IDE like Visual Studio.
I think expecting to have a perfect dev. in 2 weeks is probably a bit ambitious - but if they're good, they'll get productive quickly.
I was exactly such a developer not long ago (but I did have some *nix experience way back).
For me personally, I found the initial transition very easy. There are adequate tools for everything you need to do to at least get coding. The second phase was very difficult - finding exactly the right tools for what I was doing, and how to use those tools. I was dropped into this particular project alone, so I had no one but Google to ask, and it did take a long time to learn the keyboard shortcuts and whatnot of the new IDEs and compiler switches.
I felt, at the time, that if I had had someone to ask questions of, the whole thing would have taken a lot less time.
So long answer short: I think any good programmer won't have trouble with the easy stuff, but make sure the new dev is told frequently and in a friendly manner that everyone else is there to help answer questions.
I've attempted to switch to Linux/Unix many times. I can basically find my way around the box and do development [if I've got Mono]. Now, I can be equally as efficient in terms of basic user requirements on just about any box in a short amount of time, but if you expect me to be able to figure out all the installation, configuration and all the other stuff that comes with system maintenance in that short a period of time, I daresay I'd pull all my hair out before the two weeks was up. Invariably, someone will ask me to do something I have no idea to do in Linux/Unix and will end up switcing back to Windows because I can easily do it in a short time.
I'd say if they have other people to ask questions, sure, it's a piece of cake. If you expect them to kind of hit the ground running as a self starter, it's doubtful.
Great developers will be great on any platform. It may take him a little while, but if he is the "gets things done" sort, he should be able to get up to speed and make positive contributions to the project.
I think yes, but you might need to be patient for a longer ramp-up time. An idea: give him a Windows box with a Linux virtual machine running inside (or vice-versa), so if he runs into something he can't do quickly in Linux, he can switch over to Windows for that particular task until he becomes more proficient on the Linux side. This may mitigate some of the "separation anxiety" some windows users have when switching to Linux. Think of it as "Linux with training wheels."
Good programmers is good programmers, and they're hard to find. You can make it work if you want to.
Well if he really is a guru, I would say yes. Many studies show that a good programmer produces more that 10 times as much useful work in a day as an average programmer. A real guru probably produces 100 times as much.
So given a choice between a WIndows guru and an average Linux guy, I'd ttake the guru any day.
Why can't you hire a Linux guru instead?
That's funny how many people have come to declare "Yes sure he can".
Why nobody asks whether he would want to?
There is no doubt that Windows guru (if that is true) can handle the Linux stuff.
The only thing you should ask yourself is how much time do you have 4 the project, as you can't expect somebody that was never developing in Linux to be as fast as someone else who does that for some time.
If you can afford to let the man have some time to take a running stance, you should give him a go.
I think it depends. If you take away a man's Visual Studio, you are halving his productivity right there. If you are doing everything in emacs with commandline compilers, you've probably just lopped off another half of his productivity. Now, some of this will creep up over time as he becomes more familiar, but you can pretty much bet that this guru will never be as productive on Linux without the IDE.
If I can remember back into the Bronze Age, when I learned programming on Unix, the technique I used was to learn things as close to one at a time as I could. I didn't learn vi until I was already reasonably comfortable with C. Then I learned make, and then studied the Unix API. Eventually, it got to the point where I was just learning what I needed to know when I needed to know it, but it took months.
At least the guy you're talking about is proficient in C and C++. Get him a halfway decent IDE if he doesn't want to tackle vi or Emacs and make. The big question then is the APIs in use; they may take some time to internalize. And make sure you've got somebody to answer the simple little questions and do some of the smaller but potentially confusing things for a while.
Is there any way to make an installer that is very user friendly?
I know it's impossible for a Next Next Finished installer but what can I do to ease the process?
Windows platform.
Thanks in advance.
If you've got a very simple application and basically just need to copy a few files, I'd suggest looking at NSIS. It's very simple and you can probably have an installer done in a couple of days.
If you're developing software for a corporate environment where network rollouts are a priority, then you'll probably want to take a closer look at Windows Installer and Windows Installer XML (WiX). (Warning: a very steep learning curve - you'll want to set aside a few weeks and probably read this book to help get started)
If you want the benefits of MSI, without the hassle of learning the underlying technology then a commercial tool such as Installshield is your best bet. It's not cheap but you'll get something out the door pretty quickly.
Long term I'd advise learning Windows Installer technology. It's something overlooked by most developers, it's often seen as crazy voodoo that is overly complicated and unnecessary, in reality it's rather quite simple, just a database with a whole bunch of rules, conditions, and quirks that take a bit of getting used to :)
Try BitNami WAMPStack it is open source and free (you also have Linux and OS X versions)
If I understand your question correctly, I'm not sure how you didn't find this already...
http://www.wampserver.com/en/
The Free MS Windows replacement operating system ReactOS has just released a new version. They have a large and active development team.
Have you tried your software with it yet?
if so what is your recommendation?
Is it time to start investigating it as a serious Windows replacement?
Targeting ReactOS specifically is a bit too narrow IMO -- perhaps a better focus is to target compatibility with WINE. Because ReactOS shares so many of its usermode DLLs with WINE, targeting WINE should result in the app running just fine on ReactOS.
Of course, there will always be things that WINE can't emulate well (hence the need for ReactOS). In this way, it seems that if something runs in WINE, it will run in ReactOS, whereas the fact that something runs in ReactOS doesn't mean that it will necessarily run in WINE.
Targeting WINE is well documented, perhaps easier to test, and by definition, should make your app compatible with ReactOS as a matter of course. In this way, you're not only gathering the rather large user base of current WINE users, but you're future-proofing yourself for whenever anyone wants to use your app with ReactOS.
In their homepage, at the Tour you can see a partial list of office, tools and games that already run OK (or more or less) at ReactOS. If you subscribe to the newsletter, you'll receive info about much more - for instance, I was quite surprised when I read most SQL Server 2000 tools actually work on ReactOS!! Query Analyzer, OSQL and Books Online work fine, Enterprise Manager and Profiler are buggy and the DBMS won't work at all.
At a former workplace (an all MS shop) we investigated seriously into it as a way to reduce our expenditure in licenses whilst keeping our in-house developed apps. Since it couldn't run MSDE fine, we had to abandon the project - hope in the future this will be solved and my ex-coworkers can push it again.
These announcements might as well be also on their homepage - I couldn't find them after 5 mins. of searching, though. Probably the easiest way to know all these compatibility issues is to join the newsletter, or look for its archives.
I have been tracking this OS' progress for quite some time. I believe it has all the potential to really bring an OSS operating system to the masses for it breaks the "chicken and egg" problem: it has applications and drivers from the very beginning (since it aims to have full ABI compatibility with MS Windows).
Just wait for their first beta, I won't be surprised if they surpass Linux in popularity really soon after that...
Post Edit: Found it! Look at section Support Database, it's the web place to go look for whether a particular piece of hardware of some program works on ReactOS.
ReactOS has been under development for a long long time.
They were in some hot water earlier because some of their code appeared to be line by line dissasembly of some NT kernel code, I think they have replaced all of it.
I wouldn't bother with cross platform testing until they hit the same market penetration as Linux, which I would wager is never.
Until ReactOS doesn't randomly crash just sitting there within 5 minutes of booting, I won't worry about testing my code on it. Don't get me wrong, I like ReactOS, but it's just not stable enough for any meaningful testing yet!
No, I do not think it is time to start thinking of it as a Windows replacement.
As the site states, it's still in the Alpha stages. More importantly, whos Windows replacement? Yours? Your users? The former is one thing, the latter is categorically a no-go.
As an aside, I'm not really sure who this OS is targetting. It has to be people who rely on Windows software but don't want to pay, because people who simply don't want Windows can use MacOS / Linux, and the support (community or otherwise) for these choices is good.
Moreover, if you use Linux you already have some amounts of Windows software support via Wine.
Back to people who rely on Windows software but don't want to pay. If they are home users they can just simply pirate it, if they are large business users they already have support contracts and trained people etc. It's hard enough for large businesses to be OK to update to new versions of Windows, let alone an open source replacement.
So I suppose that leaves small businesses who don't want to obtain illegal copies of MS software, can't afford the OS licences and rely on software that only runs on Windows and has bad of non-existent Wine compatibility.
It is a useful replacement for Windows when it runs 'your' software without crashing. At the moment it is not a general purpose os as it is too unstable (being only alpha) but people have used ReactOS successfully in anger for specific tasks already. As a windows replacement it has multiple potential uses, sandbox systems, test and development systems, multiple virtual instances, embedded devices, even packaging/bundling legacy apps with their own compatible o/s. Driver and application compatibility, freed from Microsoft's policy of planned obsolescence and regular GUI renewal, what's not to like?
Despite primarily being a windows user, I am a huge fan of rsync. Now, I don't want to argue the virtues of rsync vs any other tool...this is not my point.
The only way I've ever found of running rsync on windows is via a version that is built to run on top of Cygwin, and as Cygwin has issues with Unicode, so does rsync.
Is anyone familiar enough with the workings of rsync to say if there are any real technical programming hurdles to porting rsync to a native Win32 binary?
Or is it maybe that there has just never been enough interest from windows users to care to port it over?
Partly I ask because I'm am considering trying to take on the task of starting a port, but I want to make sure there's not something I'm missing in terms of why it may not be possible.
The way that windows locks open files might cause an issue requiring you to hook into the Volume Shadowcopy Service.
About two years ago this fellow ported the algorithm to C#. I haven't taken a look at the code (or the provided binary), but it might be a place to start looking or someone to try contacting.
http://www.russiantequila.com/wordpress/?p=8
I've been evaluating an effort to undertake a win32 port as well. I don't believe anything major would block it, but evidence from both the rsync mailing list and another discussion points to a heavy reliance on unix fork() system calls. Using threads appears the way to go for win32.
Threads vs. Fork discussion
(disclaimer: i promise, i don't google myself, but google analytics brought me here)
i went through porting rsync to .net (sig11's link is my blog). there are no technical hurdles, just practical ones. as was already said, the code is rather... dense. difficult to follow, and complete lack of comments. i'm more than happy to make my work available, but unfortunately, since it was part of a commercial effort, it's not in significantly better shape.
i have, on a number of occasions, messed around with the idea of reverse-engineering the protocol and doing a ground-up implementation that's wire-compatible with the existing one, but ... a bit cleaner to work with. i've even started a wiki to that effect, but... as you can see from the lack of contents there, other item have taken priority. if anyone would like to work with me on this, that may be the impetus i need to get going.
the concept of the tool is great, as is the functionality it offers, however it's rather limited outside the *ix space, and could definitely benefit from an api.
wiki link for reference:
http://www.russiantequila.com/wiki/index.php?title=Main_Page
Have you seen this:
http://www.itefix.no/i2/taxonomy/term/39
I have used cwrsync without any problem (and with the much of the usual cygwin misery), but I haven't had any need for unicode filenames, so I've not seen that problem.
I don't really know why there isn't a native Win32 port, but I did look at the source a while back because I implemented a similar delta-copy system in C#. As one would expect from the world of brilliant *nix hackers, the source is largely single-character variable names and a total absence of comments, which isn't terrible helpful and might be rather off-putting to would-be porters.
I would really appreciate a port of rsync to MS-Windows such that it can be built using Visual Studio. I am encountering various protocol errors at random, somewhat intermittently. I am using rsync to distribute sw to a grid of around 200 machines and typically get around a a dozen failures. I am using GCC 4.4.2 and the latest cygwin to build rsync v3.0.7. It would help me alot if I could experiment with a version that does not require cygwin. This is because the machines in the grid already have another cygwin-based app running that is a different version to the one I have.
Having spent some time on the rsynv mailing list opinion seems to be divided as to cause of protocol errors on MS-Windows. Some say it is a bug in rsync where it failed to do a clean socket shutdown, a bug that was fixed a while ago. Others say that it is a fundamental protocol error in rsync where the client does not tell the server that it is finished, it just shuts down, causing MW-windows servers to get a RST signal on the socket, something that does not happen on Unix.