You're not re-learning DOS when you switch to linux.
Instead you're learning a true unix shell. Which gives you
access to a large library of insanely powerful, time-tested
commands that can be combined in an uncountable number of ways.
Those not only enable you to solve a large number of problems
(actually whole categories of problems) quicker and more reliable
than any GUI could but they further enable you to automate your
solutions for re-use.
What may seem "inconvenient" at first is your first
glimpse at the power of UNIX.
AOL.
But projects like Gnome and KDE (and monstrosities like CDE before them) aim to hide
all this under the "familiar" Mac/Windows workflow. Most people who use Unix
are presented with an inferior version of Windows, not with the shell.
As a side note... has it ever occurred to anyone else that maybe the reason certain books are "classics" is because of school teachers requiring all their students to purchase and read those books year after year? I mean, if it weren't for being forced to read them in school, I would never have read The Tale of Two Cities, Mary Shelley's Frankenstein, The Scarlet Letter, etc. How many people would really go to a bookstore, pick up one of those and think, "Wow, this looks like a really interesting, enjoyable read. I think I'll buy it"? I doubt not nearly enough for them to be considered "classics."
They're not classics because they are action-packed and fast-paced
(although as I recall it, both Two Cities and Frankenstein are).
They are classics because they are ground-breaking and have influenced later literature.
And I guess because they are still worth reading.
Worse -- he knows Visual Basic and admits it.
He could just have listed Fortran and assembly,
and we'd have worshipped him as an Old School physics geek.
This is almost as bad as watching "Sound of Music"
and realizing that Fräulein Maria probably has sex with Von Trapp halfway
through the movie.
Do you craft the IMAP requests by hand over Telnet?
Actually, last time I used IMAP for backup, I used telnet and the RFC.
Finding the IMAP command to dump the whole mailbox wasn't too hard.
(This was in an Exchange+Outlook place and it was the easy way to get the mails in an open format.)
If not, then you have to place some measure of trust in your IMAP client, otherwise the client, say Joe's IMAP Client, could just as easy mail back to him the fact that you logon to imap.gmail.com with credentials randomuser and sillypassword. When has running "on your own computer" meant anything as to the validity of software?
Maybe never...
The real point is, if you use a standard protocol
you have a lot of standard software to choose from.
What you call "Joe's IMAP Client" is in reality most major email clients --
free or otherwise.
My hatred of Java has nothing to do with speed. The platform has become a giant morass of 'enterprisey' 'solutions' that create more need for more 'solutions'. And all Java 'solutions' must somehow involve XML, because it's standard, and enterprisey.
I sympathize. However, that is hatred for J2EE, not Java.
I think he makes it pretty clear that he has a problem with the dominant(?)
culture around Java, not Java itself.
There's not much one can do about that, except stay away
(and post on Slashdot).
First, which applications care about when DST starts or ends? Almost none.
Any application that schedules anyting. Which is almost *every* non-trivial application in the world.
You cannot be serious.
I have two such packages (0.5%) on my Linux system: cron and at.
They surely handle DST, timezones etc in some more or less complex way.
But not even that is very complex: if the user says at some-time command
all at has to do is to calculate the (first) corresponding Epoch time in the
user's time zone. Then it can forget all about time zones and use UTC.
Lines like:
"This malware is very professionally written and produced. Which of course means it's not written for fun."
might annoy some, though. [---] And Linux zealots are sure to jump on the above quote with all their hearts.
Not just Linux zealots.
If you cannot write good code for fun, you cannot write it for money, either.
I'm betting that the reason so many of these applications have their own TZ info is that the interface to the existing TZ information is weak. If your only interface is the POSIX API, about all you can tell is whether a time you give is in DST or not. If you want to do anything reasonably fancy (e.g., "Is DST this weekend?" or "what time does DST start/end?"), there is a lot more work involved: you have to create multiple unix times, query the POSIX API for each one, and check the flag returned. And the POSIX API is then doing a lot more work than you really care about, which means wasted time there, too.
Instead, with your own TZ information, you can have your own internal API that accesses exactly the information you want, in the most efficient manner that you can develop (which may not be the most efficient possible given skill and/or time available).
Still a stupid reason.
First, which applications care about when DST starts or ends? Almost none.
Second, what is more polite to the end user:
to call a C89 function iteratively and waste a few milliseconds (you may be able to cache the result, and/or use a binary search),
or to subject her to a maintenance nightmare?
If you roll your own, you have to collect DST data for all cultures and countries,
get it right,
and explain to the users that your software may break at any time due to
political decisions, while all other software continues to work properly.
I suspect that this all is the reason why, for example, Java has its own TZ info built-in, rather than calling to the C API
Not Invented Here is a safer bet when it comes to Java...
If you want a good example of a broken standard C API, try locales.
Environment variables affecting the workings of a wide range of function calls,
and no sane way to (for example) format a date or compare strings in some other
locale's format without expensive setenv(3) calls which affect the whole process.
The syntax is not confused: quite the opposite. It is consistent and very minimal.
That's the problem for me. I prefer a richer (less minimal) language,
so that my programs can be minimal.
I have only hacked a single major Tcl program,
and it was not enjoyable. It felt like badly designed C code, only with
a more verbose syntax... and no type checking.
We know that many of our emails never reach their destination.
Do we? Where are the statistics?
A large Swedish ISP (Telia) lost a lot of mail some weeks back.
They got a lot of bad publicity from that -- and rightly so.
I still expect mail sent by me to either bounce or arrive to the recipient mailbox.
The thing that worries me is what happens after local delivery:
(a) it gets discarded by broken-by-design anti-spam software, or
(b) the recipient never reads it because it is lost among all the spam.
With Opera (mini and, i think, mobile), the pages you request are sent via Opera's servers, where they are put through some kind of compression. The upshot is that not only is Opera quicker, but I can visit almost twice the number of pages for my money.
Thanks for mentioning it so I can avoid Opera Mini.
I don't really see why a central proxy is significantly faster than a phone with
a well-designed name resolver plus a well-designed browser, and a web server
which supports Content-Encoding:gzip. Unless servers normally don't
compress their responses... hm.
I should reread the Apache documentation.
Nah, don't bundle it. Most people don't need it. Seriously, 99% of people have no use for a compiler on their machine.
They have no use for it because it isn't bundled.
People who write software have to assume there is no compiler on the target,
and adapt to it.
I'm not saying a compiler would mean anything drastic at this late point.
But if the commercial Unixes had shipped with one in the 1980s...
no gcc, and no Linux or *BSD. Uh, maybe we should be grateful they didn't?
I still don't see what the problem is here. There are two common ways of doing it. Mac and Gnome do it one way, Windows and KDE do it the other. *shrug*
I had a fit over this 18 months back (if I recall correctly, when the Gimp changed from Yes-No to No-Yes)
and did some research (Message-ID: <slrned8i4a.2t1.grahn+nntp@frailea.sa.invalid>)
If you look at simple Yes-no and Ok-Cancel choices, it seems to me that Mac was the odd exception before Gnome (or GTK?) switched .
Ok-Cancel isn't just Windows and KDE:
it's also AmigaOS, Motif and just about every pre-Gnome X11 GUI I could find.
It appears to be loved by Telecom people, so a fair guess is that it sucks.
The Wikipedia article references horrors like the OSI model, the SS7 protocols
and Diameter -- not encouraging.
[line numbers]
I didn't say you couldn't do it. But it requires installation of a plugin for something that basic, and it doesn't really work that well.
Don't you mean "installation of a plugin for something that BASIC"?
(Seriously, why waste 3--4 columns on line numbers?
You only care about them when the compiler whines, and then you have
a command to go to line n, you have a line number in the status bar,
and the option to set things up so you can jump to errors.)
Dual-core means that for most cases, I can run a video encode, a backup/compression process, a long-ish compilation (of the sort that doesn't like 'make -j2')...
A broken Makefile, that is. I have them too.
... etc -- not so much all at once, as I can fire off any background process and not worry about it, as I have a whole other core to use. It's shameful -- Amarok will occasionally use 100% of one core, and I won't notice for hours.
I bet you would be mostly fine with one core, too.
Nothing really bad happens to overall responsiveness on my system when
I have something running at 100%. (That's with Linux; I have a feeling Windows is worse).
The only real usefulness of SMP/multi-core I have seen with my own eyes is on multi-user servers.
You can support a lot of simultaneous users with a few cores, because they are
usually not likely to all run batch compile jobs at once.
I don't get it. We can argue the merits of data exchange formats 'till we're blue in the face; yet I cannot see why XML is so popular. For the majority of applications that use it, it's overboard. Yes, it's easier on the eye, but
Easier on the eye than *what*?
Virtually all languages I have encountered are easier to read and edit than XML-based languages. Most are so simple they can be parsed with sed or awk.
The thing that puzzles me, is why it's used so much on the web.
My cynical conclusion (so far, and as an onlooker) is that we have a whole industry
more interested in architecture and Holy Grails than in getting work done,
and that someone is, surprisingly, willing to pay for it.
Phones and instant messaging interrupt the recipient. Sending out a "Drinks at XYZ tonight?" email to five coworkers is not worth disrupting five people with phone calls who could otherwise check their email on their own schedules.
Using a phone when it is not necessary is even worse in many cases.
And then there's my favorite: people who send you mail and then --
two minutes later when you are almost done writing the reply --
show up at your desk to repeat the question orally.
Thank you for wasting my time and interrupting me!
(Of course, sometimes it is appropriate to mail background material for a discussion.)
Emacs and etags are your friend. Meta-. zips to the function under the cursor. C-s for incremental search. Meta-x grep-find for any other search.
More generally, if you are going to be browsing large masses of code,
you need to be familiar with your editor, and it needs to be good.
It needs to be fast too, and the taller the screen you can afford, the better.
I see many people working in editors they don't understand beyond the simplest editing commands,
and it certainly hurts their understanding of the code.
It doesn't matter if it's Emacs, vi, or Eclipse when you don't use the bloody thing!
Reminds me of an Agave plant we had out behind our house.
For my entire childhood it was just this big spiky Aloe like bush behind the house. About 5 feet tall. Then one time when I was in my late 20's it grew this absolutely gigantic spike about the height of a telephone pole, flowered, and then produced hundreds of little budding plantlets that fell off and took root. The original plant then promptly died.
You probably meant "Agave" the second time too. Aloes are similar, but unrelated.
Agave and bamboo are famous for dying after flowering, after many years.
I don't really see why a palm which behaves like that is big news.
Maybe more interesting that it's still possible to find new species of tree on Madagascar
(where deforestation is a big problem).
And of course, if you look at plants which grow in one year, then flower and die in the
second year, there are tons of them in temperate climages -- many vegetables, for example.
I don't think there's any replacement for talking to the real-live developers who wrote it. Failing that, any design documentation they left behind. Failing that, just get a task to do, and try to get it to work. Nothing like learning by doing.
Yup.
I see newbies fall into the trap over and over again
-- trying to understand it all just by spending weeks wading through code,
forgetting one part as they read about the next.
I do it myself now and then (and probably pick up a few things along the way),
but it's only when I have a specific goal
(fixing this bug, adding that feature)
that I start learning for real.
Unfortunately, the best tool for understanding code is experience. Not theory and not some fancy visualization program. Once you've seen a lot of different code, you come to recognize what each person was thinking when they wrote it.
I'm with you so far.
Getting inside the head of the previous maintainer is one important step.
Was he sloppy or pedantic?
If he knew about a problem, would he expose it or try to cover up?
Did he just learn about Developmend Fad Of the Year and was eager to try it out?
Was he a Lisp/C/ancient C++/C++/Python/etc fan?
Once that kind of thing comes easily, you no longer find it necessary to bitch about each different programmer's coding style (as some do).
I am happy that works out for you, but I never learned that trick.
Other people's code still looks like crap to me 90% of the time.
So in a way, the guy who posts this question is lucky to have such a big pile of code in front of him.
He is lucky, because maintaining other people's crappy code is something you need to learn
before you can become a Real Programmer.
Writing from scratch is something students do.
Maintaining crappy code is also fun, in a way.
It's a bit like solving crossword puzzles -- a hobby of mine --
at first it seems overwhelming, white squares everywhere.
Then you solve one part in a corner, and another, and it becomes easier and easier
as you go.
file data is stored in chunks of a fixed size called inodes; same idea as Windows block size option; and this size is predetermined at time of formatting and stored as part of the filesystem headers... w/ 4096 byte inode size, a 1 byte file consumes as much disk space as a 4096 byte file... exactly 1 inode
You use the term "inode" incorrectly.
An inode is the unnamed, but numbered, file which a file name
(or several file names, if there are hard links) refers to.
There's probably a decent Wikipedia article which explains this.
I suppose what you are talking about is called a "block" or something.
Slashdot Mirror
AOL. But projects like Gnome and KDE (and monstrosities like CDE before them) aim to hide all this under the "familiar" Mac/Windows workflow. Most people who use Unix are presented with an inferior version of Windows, not with the shell.
They're not classics because they are action-packed and fast-paced (although as I recall it, both Two Cities and Frankenstein are). They are classics because they are ground-breaking and have influenced later literature. And I guess because they are still worth reading.
Worse -- he knows Visual Basic and admits it. He could just have listed Fortran and assembly, and we'd have worshipped him as an Old School physics geek.
This is almost as bad as watching "Sound of Music" and realizing that Fräulein Maria probably has sex with Von Trapp halfway through the movie.
Actually, last time I used IMAP for backup, I used telnet and the RFC. Finding the IMAP command to dump the whole mailbox wasn't too hard. (This was in an Exchange+Outlook place and it was the easy way to get the mails in an open format.)
Maybe never ...
The real point is, if you use a standard protocol
you have a lot of standard software to choose from.
What you call "Joe's IMAP Client" is in reality most major email clients --
free or otherwise.
I think he makes it pretty clear that he has a problem with the dominant(?) culture around Java, not Java itself. There's not much one can do about that, except stay away (and post on Slashdot).
You cannot be serious. I have two such packages (0.5%) on my Linux system: cron and at.
They surely handle DST, timezones etc in some more or less complex way. But not even that is very complex: if the user says at some-time command all at has to do is to calculate the (first) corresponding Epoch time in the user's time zone. Then it can forget all about time zones and use UTC.
Not just Linux zealots. If you cannot write good code for fun, you cannot write it for money, either.
Still a stupid reason. First, which applications care about when DST starts or ends? Almost none. Second, what is more polite to the end user: to call a C89 function iteratively and waste a few milliseconds (you may be able to cache the result, and/or use a binary search), or to subject her to a maintenance nightmare? If you roll your own, you have to collect DST data for all cultures and countries, get it right, and explain to the users that your software may break at any time due to political decisions, while all other software continues to work properly.
Not Invented Here is a safer bet when it comes to Java ...
If you want a good example of a broken standard C API, try locales. Environment variables affecting the workings of a wide range of function calls, and no sane way to (for example) format a date or compare strings in some other locale's format without expensive setenv(3) calls which affect the whole process.
That's the problem for me. I prefer a richer (less minimal) language, so that my programs can be minimal.
I have only hacked a single major Tcl program, and it was not enjoyable. It felt like badly designed C code, only with a more verbose syntax ... and no type checking.
From the writeup:
Do we? Where are the statistics? A large Swedish ISP (Telia) lost a lot of mail some weeks back. They got a lot of bad publicity from that -- and rightly so.
I still expect mail sent by me to either bounce or arrive to the recipient mailbox. The thing that worries me is what happens after local delivery: (a) it gets discarded by broken-by-design anti-spam software, or (b) the recipient never reads it because it is lost among all the spam.
Thanks for mentioning it so I can avoid Opera Mini.
I don't really see why a central proxy is significantly faster than a phone with a well-designed name resolver plus a well-designed browser, and a web server which supports Content-Encoding:gzip. Unless servers normally don't compress their responses ... hm.
I should reread the Apache documentation.
They have no use for it because it isn't bundled. People who write software have to assume there is no compiler on the target, and adapt to it.
I'm not saying a compiler would mean anything drastic at this late point. But if the commercial Unixes had shipped with one in the 1980s ...
no gcc, and no Linux or *BSD. Uh, maybe we should be grateful they didn't?
I had a fit over this 18 months back (if I recall correctly, when the Gimp changed from Yes-No to No-Yes) and did some research (Message-ID: <slrned8i4a.2t1.grahn+nntp@frailea.sa.invalid>)
If you look at simple Yes-no and Ok-Cancel choices, it seems to me that Mac was the odd exception before Gnome (or GTK?) switched . Ok-Cancel isn't just Windows and KDE: it's also AmigaOS, Motif and just about every pre-Gnome X11 GUI I could find.
SCTP.
It appears to be loved by Telecom people, so a fair guess is that it sucks. The Wikipedia article references horrors like the OSI model, the SS7 protocols and Diameter -- not encouraging.
Don't you mean "installation of a plugin for something that BASIC"?
(Seriously, why waste 3--4 columns on line numbers? You only care about them when the compiler whines, and then you have a command to go to line n, you have a line number in the status bar, and the option to set things up so you can jump to errors.)
A broken Makefile, that is. I have them too.
I bet you would be mostly fine with one core, too. Nothing really bad happens to overall responsiveness on my system when I have something running at 100%. (That's with Linux; I have a feeling Windows is worse).
The only real usefulness of SMP/multi-core I have seen with my own eyes is on multi-user servers. You can support a lot of simultaneous users with a few cores, because they are usually not likely to all run batch compile jobs at once.
No. Roger Waters.
Easier on the eye than *what*? Virtually all languages I have encountered are easier to read and edit than XML-based languages. Most are so simple they can be parsed with sed or awk.
My cynical conclusion (so far, and as an onlooker) is that we have a whole industry more interested in architecture and Holy Grails than in getting work done, and that someone is, surprisingly, willing to pay for it.
And then there's my favorite: people who send you mail and then -- two minutes later when you are almost done writing the reply -- show up at your desk to repeat the question orally. Thank you for wasting my time and interrupting me!
(Of course, sometimes it is appropriate to mail background material for a discussion.)
More generally, if you are going to be browsing large masses of code, you need to be familiar with your editor, and it needs to be good. It needs to be fast too, and the taller the screen you can afford, the better.
I see many people working in editors they don't understand beyond the simplest editing commands, and it certainly hurts their understanding of the code. It doesn't matter if it's Emacs, vi, or Eclipse when you don't use the bloody thing!
You probably meant "Agave" the second time too. Aloes are similar, but unrelated.
Agave and bamboo are famous for dying after flowering, after many years. I don't really see why a palm which behaves like that is big news. Maybe more interesting that it's still possible to find new species of tree on Madagascar (where deforestation is a big problem).
And of course, if you look at plants which grow in one year, then flower and die in the second year, there are tons of them in temperate climages -- many vegetables, for example.
Yup. I see newbies fall into the trap over and over again -- trying to understand it all just by spending weeks wading through code, forgetting one part as they read about the next. I do it myself now and then (and probably pick up a few things along the way), but it's only when I have a specific goal (fixing this bug, adding that feature) that I start learning for real.
I'm with you so far. Getting inside the head of the previous maintainer is one important step. Was he sloppy or pedantic? If he knew about a problem, would he expose it or try to cover up? Did he just learn about Developmend Fad Of the Year and was eager to try it out? Was he a Lisp/C/ancient C++/C++/Python/etc fan?
I am happy that works out for you, but I never learned that trick. Other people's code still looks like crap to me 90% of the time.
He is lucky, because maintaining other people's crappy code is something you need to learn before you can become a Real Programmer. Writing from scratch is something students do.
Maintaining crappy code is also fun, in a way. It's a bit like solving crossword puzzles -- a hobby of mine -- at first it seems overwhelming, white squares everywhere. Then you solve one part in a corner, and another, and it becomes easier and easier as you go.
The documentation is encoded into CPP macro definitions? Gross.
You use the term "inode" incorrectly. An inode is the unnamed, but numbered, file which a file name (or several file names, if there are hard links) refers to. There's probably a decent Wikipedia article which explains this.
I suppose what you are talking about is called a "block" or something.