If programmer were a job with proper qualifications every certified programmer would be able to learn every language in a matter of weeks while reading the (properly documented) code of his predecessor. Programming Languages are not that different but the small differences wether you need 1 or 10 (easy to learn) commands for a given action can make a huge difference in reducing complexity.
Popular blogs would have an advantage here and for unpopular ones the one original Bittorrent Seed would be enough and not much worse than hosting it on Webspace.
IRC is just End-to-End-Relaying so you can use SSL on any server to encrypt your messages and leave your commands unencrypted as long as everyone who needs to listen has the matching decryption in their IRC-Client.
Just for the record: How many programs did you encounter that were not in an apt-repository but provided.dev files on their site? My experience with Gentoo lead me to find almost only source-code-only-tarballs of the programs not in portage precisely for the same reason there were no ebuilds: Nobody cared (to make an ebuild for portage, to make a binary rpm/deb)
Re:Why write a book on "easy to use linux"?
on
Point and Click Linux
·
· Score: 2, Insightful
Even though Windows claims to be binary-backwards-compatible and probably even is better in this department than Linux the User-Interface has gone through more changes than most Linux UIs. Sure, KDE isn't FvWM but if you take a Windows 3.11 User and put them in front of a Windows XP PC he wouldn't have much of a clue what to do either at first. At least with Linux the commandline interface and most mature apps are relatively stable (KDE and Gnome are not mature at the current stage). Windows adds new bells and whistles in every version even without good reason. Changes in mature Linux Apps just occur when there is a good reason for it.
Linux doesn't play well with NTFS (mounts it read-only)
AFAIK Windows doesn't play well with any non-MS Filesystem (doesn't even recognize them as filesystems, not to mention mounting them) so Users might want to ask themselves who is behind the other. (I know you probably know this, I just thought I'd mention it)
I read it recently and the author did a great job in explaining the strong points of the language instead of writing just another boring introduction to beginner level programming tools like if, for,... like so many other books on programming languages do.
Wether a book is better online or as hardcopy depends on the style. If it is mostly for looking things up an online copy is really useful, if you read the whole book hardcopies are much better (some books can be both).
I agree. This book is definitely worth reading although if you are from germany you shouldn't buy the translation, it is seriously flawed since the translator didn't have much of a clue.
Perhaps we don't need support contracts but managers who stand up for their own mistakes and don't blame them on their IT supplier. Remember: There is no "Computer Error", just human error at different parts of the chain. Most screwups are not the (sole) fault of the IT Equipment but mostly from a mix of problems in IT or another department which management should recognize early but fails to do so.
The most important advantage of a license would be the possibility to revoke them for users proving to be complete idiots even after a reasonable number of warnings which would spare the rest of us the spam-zombies created by this stupidity.
It IS impossible to make anything (not just computers) 100% secure. Sure, you could kill all humans worldwide so nobody could think of new exploits but as long as there are users that want to use the network/host in another way than it was intended it is not possible to get 100% security.
If Linux would have 90% of the Market we would have x% Linux 2.2, y% Linux 2.4, z% Linux 2.6, a% SuSE, b% Redhat, c% Gentoo, i% x86 Linux, j% PPC-Linux,...
The market would be dominated by one OS much less even if Linux had this market share.
I did almost the same thing last weekend with my headless Linux Server/Router. The only kernel option I had to recompile was the driver for the new onboard network chipset and the new filesystem (reiser4). I simply made a tarball of the whole system (with everything running) copied it over to the new system (I had compiled the new kernel before on the old system) and installed the bootloader on the new harddisk. Except for the slow tarball creation and extraction it took me about half an hour of configuration and hardware moving. The old system was a (P2-based) Celeron 300A (one of the first Celeron ever built), the new one is a (P3-based) Celeron 1700 Mhz with onboard Gigabit Ethernet. Since I copied the few files that changed during the tarball moving manually after the big data move I had a total downtime of my Router of about 15 minutes which was mostly hardware moving.
I do think we made progress in some areas. However I do not blindly embrace everything new just because it is new. It must be better in my opinion. Unix has it's flaws but it also has some pretty interesting design principles and abstractions. Eric S. Raymond made a nice list in his book The Art of Unix Programming http://www.catb.org/~esr/writings/taoup/html/ch01s 06.html and while I don't agree with everything he writes I witness the "magic" of things like pipes and clean textual config-files everyday while at the same time I see the problems with more recent approaches. The ideal way to develop something new would be to take the good parts from the old tools and correct the flaws that have shown in practical use and if this means stripping out 3/4 of the "features" then this is a good thing even though marketing might say otherwise.
I also tend to like a choice about the tool I use for every single task instead of buying everything as a package (e.g. IDE). I would like a language with the power of C and the power and syntax of modern scripting languages where you could do things low-level if necessary but don't have to if you don't want/need to and where you could understand a program by reading it without consulting an API Documentation or following the counter-variables of each and every for-loop (better: each-Iterator-concept like in ruby).
See, this is a common mistake. For thirty years or so now people say, tomorrow users will be able to program themselves, but instead the programming tasks just get more complex.
Users doing ALL the programming (even the programming of the programming environments/languages) won't happen before real AI is developed which IMHO is scheduled for "never" (or at least not in this century).
You're probably wasting a lot of time trying to remember if it's put() or add() or addElement()
You are right, it shouldn't be necessary to remember those. That is why most other language use a consistent naming scheme in their standard libraries and publish a style guide or something similar for third party library development. Java is terribly inconsistent in this matter, probably because they had too many designers working on the language instead of one person deciding these things.
a primitive tool such as emacs/JDEE
If you would look behind the first few hours of Emacs usage you would know that Emacs is propably the most advanced development environment today. You can automate pratically everything and there are modes for almost all the features your typical IDE offers. In addition you can customize it to fit your personal style AND the most important feature of all for software engineers choosing the right tool (language) for the job: you can use emacs with almost every language out there without relearning everything. For further information you should look at http://www.emacswiki.org/
Last semester I had to do a group software engineering task in a group of 8. In the first meeting someone spent over 1 hour to figure out how to use cvs from eclipse on his laptop and afterwards couldn't even say how he got it working so all the others using eclipse had to work it out for themselves too. I used Linux commandline, cvs commandline and Emacs and was halfway through reverse engineering of the codebase to which we should add something by the time they got their eclipse working. Later they ran into trouble because their code ran in Eclipse but not without it (on the demonstration server&client). This real world experience is one of the main reasons I always see IDEs with more scepticism than most other people (besides: I like the commandline better in any situation, not just development, but thats personal preference)
Slashdot Mirror
If programmer were a job with proper qualifications every certified programmer would be able to learn every language in a matter of weeks while reading the (properly documented) code of his predecessor. Programming Languages are not that different but the small differences wether you need 1 or 10 (easy to learn) commands for a given action can make a huge difference in reducing complexity.
Which is a good thing to drive IPv4 out and introduce IPv6 without problematic "solutions" like NAT
That's like saying "If there were no accidents there'd be no job for the Ambulance driver."
The Torrent can not die before the last user stops sharing and that would be the blogger.
Popular blogs would have an advantage here and for unpopular ones the one original Bittorrent Seed would be enough and not much worse than hosting it on Webspace.
IRC is just End-to-End-Relaying so you can use SSL on any server to encrypt your messages and leave your commands unencrypted as long as everyone who needs to listen has the matching decryption in their IRC-Client.
Just for the record: How many programs did you encounter that were not in an apt-repository but provided .dev files on their site? My experience with Gentoo lead me to find almost only source-code-only-tarballs of the programs not in portage precisely for the same reason there were no ebuilds: Nobody cared (to make an ebuild for portage, to make a binary rpm/deb)
Even though Windows claims to be binary-backwards-compatible and probably even is better in this department than Linux the User-Interface has gone through more changes than most Linux UIs. Sure, KDE isn't FvWM but if you take a Windows 3.11 User and put them in front of a Windows XP PC he wouldn't have much of a clue what to do either at first. At least with Linux the commandline interface and most mature apps are relatively stable (KDE and Gnome are not mature at the current stage). Windows adds new bells and whistles in every version even without good reason. Changes in mature Linux Apps just occur when there is a good reason for it.
I read it recently and the author did a great job in explaining the strong points of the language instead of writing just another boring introduction to beginner level programming tools like if, for,... like so many other books on programming languages do.
I second that. It is a truly interesting read. It is also available online at http://www.catb.org/~esr/writings/taoup/
Wether a book is better online or as hardcopy depends on the style. If it is mostly for looking things up an online copy is really useful, if you read the whole book hardcopies are much better (some books can be both).
I agree. This book is definitely worth reading although if you are from germany you shouldn't buy the translation, it is seriously flawed since the translator didn't have much of a clue.
Perhaps we don't need support contracts but managers who stand up for their own mistakes and don't blame them on their IT supplier. Remember: There is no "Computer Error", just human error at different parts of the chain. Most screwups are not the (sole) fault of the IT Equipment but mostly from a mix of problems in IT or another department which management should recognize early but fails to do so.
The most important advantage of a license would be the possibility to revoke them for users proving to be complete idiots even after a reasonable number of warnings which would spare the rest of us the spam-zombies created by this stupidity.
It IS impossible to make anything (not just computers) 100% secure. Sure, you could kill all humans worldwide so nobody could think of new exploits but as long as there are users that want to use the network/host in another way than it was intended it is not possible to get 100% security.
Even better would be to turn Web Developers off Java Script ;)
If Linux would have 90% of the Market we would have x% Linux 2.2, y% Linux 2.4, z% Linux 2.6, a% SuSE, b% Redhat, c% Gentoo, i% x86 Linux, j% PPC-Linux,...
The market would be dominated by one OS much less even if Linux had this market share.
I did almost the same thing last weekend with my headless Linux Server/Router. The only kernel option I had to recompile was the driver for the new onboard network chipset and the new filesystem (reiser4). I simply made a tarball of the whole system (with everything running) copied it over to the new system (I had compiled the new kernel before on the old system) and installed the bootloader on the new harddisk. Except for the slow tarball creation and extraction it took me about half an hour of configuration and hardware moving. The old system was a (P2-based) Celeron 300A (one of the first Celeron ever built), the new one is a (P3-based) Celeron 1700 Mhz with onboard Gigabit Ethernet. Since I copied the few files that changed during the tarball moving manually after the big data move I had a total downtime of my Router of about 15 minutes which was mostly hardware moving.
AFAIK Solaris is only proven on non-x86 (correct me if i am wrong). Hosters willing to use cheap hardware might choose Linux because of this.
I just noticed /. ate my "insert name of language here" after the "definition 4 of"
I do think we made progress in some areas. However I do not blindly embrace everything new just because it is new. It must be better in my opinion. Unix has it's flaws but it also has some pretty interesting design principles and abstractions. Eric S. Raymond made a nice list in his book The Art of Unix Programming http://www.catb.org/~esr/writings/taoup/html/ch01s 06.html and while I don't agree with everything he writes I witness the "magic" of things like pipes and clean textual config-files everyday while at the same time I see the problems with more recent approaches. The ideal way to develop something new would be to take the good parts from the old tools and correct the flaws that have shown in practical use and if this means stripping out 3/4 of the "features" then this is a good thing even though marketing might say otherwise.
I also tend to like a choice about the tool I use for every single task instead of buying everything as a package (e.g. IDE). I would like a language with the power of C and the power and syntax of modern scripting languages where you could do things low-level if necessary but don't have to if you don't want/need to and where you could understand a program by reading it without consulting an API Documentation or following the counter-variables of each and every for-loop (better: each-Iterator-concept like in ruby).
See, this is a common mistake. For thirty years or so now people say, tomorrow users will be able to program themselves, but instead the programming tasks just get more complex.
Users doing ALL the programming (even the programming of the programming environments/languages) won't happen before real AI is developed which IMHO is scheduled for "never" (or at least not in this century).
Last semester I had to do a group software engineering task in a group of 8. In the first meeting someone spent over 1 hour to figure out how to use cvs from eclipse on his laptop and afterwards couldn't even say how he got it working so all the others using eclipse had to work it out for themselves too. I used Linux commandline, cvs commandline and Emacs and was halfway through reverse engineering of the codebase to which we should add something by the time they got their eclipse working. Later they ran into trouble because their code ran in Eclipse but not without it (on the demonstration server&client). This real world experience is one of the main reasons I always see IDEs with more scepticism than most other people (besides: I like the commandline better in any situation, not just development, but thats personal preference)