Windows got ahead because a Sun Workstation cost 10x as much.
No, it got ahead because a mass psychosis told people there was nothing else.
In the early 1990s, nothing but the PC and the Mac existed in the public mind. The C64, Atari ST and Commodore-Amiga didn't exist (although every other kid had one).
The Sun machines didn't exist if you weren't into some very specific niches -- not because they weren't suited there, but because of the PC psychosis.
At that time I was an embittered Amiga user. We never got mentioned in the press or on TV, even though the Amiga at the time was both cheaper and more powerful that the PC+Windows 3.x combo.
There seemed to have been an narrow opening in the mid-1980s where people experimented with proprietary Unix on PC hardware. Even Commodore made one for the Amiga. As far as I can tell that window closed quickly -- most of those systems sucked, and I suppose they also suffered from the then-rampant Unix fragmentation. SCO Unix was the only one people are likely to remember.
The music industry had to be dragged kicking, clawing, and screaming into the 21st century. If it weren't for Napster and iTunes we'd all still be driving down to the record store to buy $15 CD's, just to get the one or two songs you actually want and the 10 other songs that are complete filler.
I never understood that idea.
The artists I like enough to buy from don't produce filler songs, and tend to produce albums which fit together.
I bought a "best of" by one of my favorite bands (The Triffids) recently, but I couldn't listen to it -- the "best of" songs spanned five years or so, and didn't fit together on one album.
I don't care if you're not doing it for money (though, you sound like you might do it for fame). It's wrong.
As he explained it, it sounds as if he's concerned about the outfit's customers.
It's not unheard of -- that people care about the wellbeing of other people.
(That Christ guy you mention in the subject line did, for example)
Hacking is hacking into remote targets. Cracking is cracking software on your local computer by reverse engineering and debugging it.
You're probably right about cracking, but hacking has many different meanings.
I tend to use it as "to do a quick-and-dirty bit of programming" and in context people seem to understand what I mean.
He may be away of it. But I think he is like a lot of other Unix/Linux people, who has some degree of autism. Where they have a hard time dealing with change.
Personally I have a hard time dealing with change for change's sake.
That's a viable option, like many others, but I still think that a very big and very long text log is something that could be optimized by a database.
Why? On a modern system you can grep (or perl -ne, or whatever) hundreds of megabytes (far more than any syslog I've seen) in a few seconds. Less if you gzip it first so disk I/O gets minimized.
Agreed. I submitted this post yesterday, by the lead developer for rsyslogd (the most common syslog daemon in linux these days). He makes the point that most of the complaints made are actually wrong if they'd bothered to look at the last 10 years of development and IETF work around syslog.
But about this part of what he wrote:
"Ages ago (2006?) I implemented high-precision timestamps (including TZ info) in rsyslog, and RFC5424 has brought them to the on-the-wire protocol. As far as I know, syslog-ng supports them for quite a while as well (but I am not a syslog-ng expert;)). However, all distributions turn high precision timestamps off and set the dumb old format as this is a requirement to keep old tools working."
I enabled high-precision timestamps on my Debian system to get a feel for them.
But I had to turn them off again: not readable enough, and took too much screen space making more log lines wrap.
The tools weren't the problem; I just couldn't eyeball the damned things!
Look, the average user is not us. The average user doesn't want to program their computer. The average user is, in fact, in the market for an expensive video telephone that also plays Angry Birds.
Isn't it possible that this is because Apple and others trained the average user to believe that?
1. Talking to people face to face, to reach consensus, to learn things, to hear gossip, new ideas, anecdotes...
2. A good and well-used wiki where anything official, semi-official or noteworthy can be found.
3. Forums, either as a News (NNTP) server or archived mailing lists.
Not a sucky web forum isolated from everything else (like Slashdot)
or email with reply-to-all chains.
For discussions within a group or a project.
4. Email, mostly for one-to-one discussions which you may want to refer to later.
5. IM, for quick questions to (or hand-holding of) someone who isn't at his desk.
Preferably using open standards so everyone can choose his IM client.
6. Sane version control of all documents, source code and other files produced.
You cannot remove any one of these without messing with the communication.
At my current workplace we have 1, 2, 4 and 5.
(3) is replaced by reply-to-all email which annoys people who aren't really interested,
and never reach others because they weren't involved when the discussion started.
(4) is replaced partly by mailing/IM:ing around copies of files, and partly by asking people rather than RTFM.
... Now, someone might argue that the hacker just grabs the logging server name from/etc/syslog.conf and attacks that was well. Well, good luck with that. We stream to a server that doesn't exist except as a honey pot, and let another server sniff the traffic and save it the usual way. But this might be overkill - we've had a dozen successful attacks and all deleted logs but none went after the remote server, nor bothered to kill off the syslog daemon.
Come on; it's not hard to secure a server if its single purpose is to be a syslogd sink.
Ssh with public-key auth, few user accounts and nothing else running except syslogd -- how are you going to crack that?
1. Time Enough for Love
2. The Number of the Beast
Writing one book about a character who travels back in time so that he can screw his mother might be excusable. Writing two is unimaginative as well as creepy.
Especially if you've already written "All You Zombies --".
I wonder what became so difficult about syncing data that it has to be re-invented all the time?
I was happy using tools like rsync, diff and unison for a long time, until the moment when even Linux desktop software is too posh to store their data in files.
The indoctrination has reached you, too.
It's not the software's data, it's your data, dammit.
It should be in a documented format, readable by any application and friendly to
rsync, version control et cetera.
This isn't a totally trivial question. I've often seen comments in forums saying that something works in kernels from the Frosty Ferret release to the Manifest Monkey release.
I think you can safely ignore anyone who refers to kernels by their silly-names.
People who want to be understood uses whatever number uname -a says.
It almost seems like you are not doing statistics as much as creating reports from data.
Maybe you should be using a database instead of a spreadsheet or a statistics program.
I don't see why even a database would be needed.
"Increasingly the administration is asking our department to collect data on various aspects of our activities, class taught, students helped, circulation, collection development, and so on."
Seems to me that information already exists in a library, and the report generation is the only thing missing.
And possibly looking into the database on the 1st of every month and writing down the number of books on a piece of paper.
Or a reply to the administration "Stop asking for these statistics and let me do my job!"
I stick in more advanced stuff into my code when I can, but that is always on the sly
Please don't do this. Resist the urge to get clever for the sake of being clever. This will almost always come back to bite you (or more likely a coworker) later in time.
With software, less is definitely more so try to write as little code as possible to solve te problem at hand.
That's not necessarily what he was saying though.
Lots of code is written caveman-style: hard to read, repetitive and buggy.
I don't see any problems with *not* sticking to such a style when extending it.
Examples: code written in pre-ANSI C but always compiled with a modern compiler;
C++ code written by C programmers ignorant of the standard library.
With long-lived software, the challenge which interests me the most is to keep it from degrading over time.
Any fool can add feature #1 and make it work, but most of them will do it in such a way that each new change
gets harder and harder to make, until finally all progress stops.
The most fun work I've done is maintenance programming where each change is easier than the previous one
because each change improves the code base.
In your perfect little CLI world, the computer wouldn't nearly have the adoption rate as it does now. That means the industry as a whole doesn't grow. As such, we wouldn't have had the advancements in hardware that we enjoy today. The fact is, while the CLI may be great for scripted routines and vertical market solutions, it sucks absolute balls at scalability in feature sets. Not the CLI itself, but the learning curve. Also, having to pipe out a fucking paragraph just to get shit done is out-of-the-question for most people.
How do you know this, when almost noone -- except us current Unix users -- have even had a chance
to try a decent CLI? Or any of the other successful Unix paradigms, for that matter.
To add to the confusion, mixing the CLI as the primary interface shell and non-standard application GUIs is even worse.
I guess you're referring to the pre-Gnome, pre-KDE X11 environment.
I don't know -- I can see a revival for that simple model.
Sure, Emacs doesn't have the same look & feel as xedit, but at least they aren't trying to control you or your system.
In fact, I'm not sure what Gnome or KDE or what's-it-name has to offer that is useful to me.
I have a root menu, a simple window manager, and an xclock in a corner. What am I missing which needs to be integrated and centrally controlled by some project?
Although most likely true, this just goes to show that adjectives follow fashion and fall out of favor.
The bible of software engineering algorithms?--The Art of Computer Programming (vol. 1-4) by Donald Knuth.
I'm pretty sure that the humble Knuth wouldn't have a problem describing himself as a Programmer.
Knuth also wrote (in an interview somewhere?) about how one interesting aspect of a programmer's work is the
jumping between abstraction levels.
One minute you're at the machine language level -- the other you're thinking of overall design, or usability.
And of course that's what he did when he created TeX.
BTW, I'm sitting with a Debian Linux machine typing this.
I wonder how they divided the work when writing ls, vi and awk?
Or the other gigabytes of excellent free software in the Debian archive?
Comments above show this paper does not study what it purports to study and draws false conclusions based on a non-understanding of statistics. Is it my imagination or are we getting more and more crap papers like this on/.?
It's so boring listening to little Perl haters. They always seem to have some chip on their shoulder as if Perl were the one language they just couldn't ever get. As if that C++ is any fun. Please, *must* I write in C++?
Now that you mention it, it's also boring to listening to the C++ haters...
I use perl for my daily tasks (scripts etc) at work and this "forgiving syntax" has been a time saver.. imho perl is (or should be) just an administrator's tool, nothing more.
That's absurd -- why should I as a normal user not use Perl for such daily tasks?
Programming is not just for admins and big software development projects.
"It seems they're more eager to put out things and see what sticks"
I guess he's not aware that this is Google's standard mode of operation as a business. Does this man live in a box, developing a browser nobody needs?
Perhaps he's questioning Google's standard mode of operation as a business?
Did that occur to you?
In my opinion the biggest problem with TCP/IP is that TCP is a stream protocol. Everyone who uses it immediately creates some sort of scheme to divide the stream into messages.
Yeah -- but dividing it in a way which suits the problem they want to solve.
I'm not at all convinced that it's feasible to design a simple and safe "one size fits all" reliable datagram protocol.
And I'm very unimpressed by the UDP-based protocols I've seen: slow, fragile, constant problems with a fast sender overloading a slow receiver, inefficient stack--application interfaces...
> The netbook Amiga will set a mark in computer history as the first portable Amiga to see the light of the day since the Amiga 1000 was introduced to the U.S. market in 1985.
This sentence is confusing. Is it trying to say that the A1000 was portable? Because I had one and I can assure you that it was not.
No, that's not what the article was trying to say.
It's just a funny way of sneaking in the name and birth year of the first Amiga.
Slashdot Mirror
Windows got ahead because a Sun Workstation cost 10x as much.
No, it got ahead because a mass psychosis told people there was nothing else. In the early 1990s, nothing but the PC and the Mac existed in the public mind. The C64, Atari ST and Commodore-Amiga didn't exist (although every other kid had one). The Sun machines didn't exist if you weren't into some very specific niches -- not because they weren't suited there, but because of the PC psychosis.
At that time I was an embittered Amiga user. We never got mentioned in the press or on TV, even though the Amiga at the time was both cheaper and more powerful that the PC+Windows 3.x combo.
There seemed to have been an narrow opening in the mid-1980s where people experimented with proprietary Unix on PC hardware. Even Commodore made one for the Amiga. As far as I can tell that window closed quickly -- most of those systems sucked, and I suppose they also suffered from the then-rampant Unix fragmentation. SCO Unix was the only one people are likely to remember.
The music industry had to be dragged kicking, clawing, and screaming into the 21st century. If it weren't for Napster and iTunes we'd all still be driving down to the record store to buy $15 CD's, just to get the one or two songs you actually want and the 10 other songs that are complete filler.
I never understood that idea. The artists I like enough to buy from don't produce filler songs, and tend to produce albums which fit together. I bought a "best of" by one of my favorite bands (The Triffids) recently, but I couldn't listen to it -- the "best of" songs spanned five years or so, and didn't fit together on one album.
First off, QUIT FUCKING TRESSPASSING.
I don't care if you're not doing it for money (though, you sound like you might do it for fame). It's wrong.
As he explained it, it sounds as if he's concerned about the outfit's customers. It's not unheard of -- that people care about the wellbeing of other people. (That Christ guy you mention in the subject line did, for example)
Hacking is hacking into remote targets. Cracking is cracking software on your local computer by reverse engineering and debugging it.
You're probably right about cracking, but hacking has many different meanings. I tend to use it as "to do a quick-and-dirty bit of programming" and in context people seem to understand what I mean.
Think of the smell.
My cousin's ~14 year old daughter went there this year. I hear there's not much geekiness at Dreamhack, and hasn't been for many years.
He may be away of it. But I think he is like a lot of other Unix/Linux people, who has some degree of autism. Where they have a hard time dealing with change.
Personally I have a hard time dealing with change for change's sake.
That's a viable option, like many others, but I still think that a very big and very long text log is something that could be optimized by a database.
Why? On a modern system you can grep (or perl -ne, or whatever) hundreds of megabytes (far more than any syslog I've seen) in a few seconds. Less if you gzip it first so disk I/O gets minimized.
Agreed. I submitted this post yesterday, by the lead developer for rsyslogd (the most common syslog daemon in linux these days). He makes the point that most of the complaints made are actually wrong if they'd bothered to look at the last 10 years of development and IETF work around syslog.
But about this part of what he wrote:
"Ages ago (2006?) I implemented high-precision timestamps (including TZ info) in rsyslog, and RFC5424 has brought them to the on-the-wire protocol. As far as I know, syslog-ng supports them for quite a while as well (but I am not a syslog-ng expert ;)). However, all distributions turn high precision timestamps off and set the dumb old format as this is a requirement to keep old tools working."
I enabled high-precision timestamps on my Debian system to get a feel for them. But I had to turn them off again: not readable enough, and took too much screen space making more log lines wrap. The tools weren't the problem; I just couldn't eyeball the damned things!
Look, the average user is not us. The average user doesn't want to program their computer. The average user is, in fact, in the market for an expensive video telephone that also plays Angry Birds.
Isn't it possible that this is because Apple and others trained the average user to believe that?
1. Talking to people face to face, to reach consensus, to learn things, to hear gossip, new ideas, anecdotes ...
2. A good and well-used wiki where anything official, semi-official or noteworthy can be found.
3. Forums, either as a News (NNTP) server or archived mailing lists. Not a sucky web forum isolated from everything else (like Slashdot) or email with reply-to-all chains. For discussions within a group or a project.
4. Email, mostly for one-to-one discussions which you may want to refer to later.
5. IM, for quick questions to (or hand-holding of) someone who isn't at his desk. Preferably using open standards so everyone can choose his IM client.
6. Sane version control of all documents, source code and other files produced.
You cannot remove any one of these without messing with the communication. At my current workplace we have 1, 2, 4 and 5. (3) is replaced by reply-to-all email which annoys people who aren't really interested, and never reach others because they weren't involved when the discussion started. (4) is replaced partly by mailing/IM:ing around copies of files, and partly by asking people rather than RTFM.
... Now, someone might argue that the hacker just grabs the logging server name from /etc/syslog.conf and attacks that was well. Well, good luck with that. We stream to a server that doesn't exist except as a honey pot, and let another server sniff the traffic and save it the usual way. But this might be overkill - we've had a dozen successful attacks and all deleted logs but none went after the remote server, nor bothered to kill off the syslog daemon.
Come on; it's not hard to secure a server if its single purpose is to be a syslogd sink. Ssh with public-key auth, few user accounts and nothing else running except syslogd -- how are you going to crack that?
1. Time Enough for Love 2. The Number of the Beast
Writing one book about a character who travels back in time so that he can screw his mother might be excusable. Writing two is unimaginative as well as creepy.
Especially if you've already written "All You Zombies --".
I wonder what became so difficult about syncing data that it has to be re-invented all the time?
I was happy using tools like rsync, diff and unison for a long time, until the moment when even Linux desktop software is too posh to store their data in files.
The indoctrination has reached you, too. It's not the software's data, it's your data, dammit. It should be in a documented format, readable by any application and friendly to rsync, version control et cetera.
This isn't a totally trivial question. I've often seen comments in forums saying that something works in kernels from the Frosty Ferret release to the Manifest Monkey release.
I think you can safely ignore anyone who refers to kernels by their silly-names. People who want to be understood uses whatever number uname -a says.
It almost seems like you are not doing statistics as much as creating reports from data. Maybe you should be using a database instead of a spreadsheet or a statistics program.
I don't see why even a database would be needed. "Increasingly the administration is asking our department to collect data on various aspects of our activities, class taught, students helped, circulation, collection development, and so on."
Seems to me that information already exists in a library, and the report generation is the only thing missing. And possibly looking into the database on the 1st of every month and writing down the number of books on a piece of paper.
Or a reply to the administration "Stop asking for these statistics and let me do my job!"
Please don't do this. Resist the urge to get clever for the sake of being clever. This will almost always come back to bite you (or more likely a coworker) later in time.
With software, less is definitely more so try to write as little code as possible to solve te problem at hand.
That's not necessarily what he was saying though. Lots of code is written caveman-style: hard to read, repetitive and buggy. I don't see any problems with *not* sticking to such a style when extending it.
Examples: code written in pre-ANSI C but always compiled with a modern compiler; C++ code written by C programmers ignorant of the standard library.
With long-lived software, the challenge which interests me the most is to keep it from degrading over time. Any fool can add feature #1 and make it work, but most of them will do it in such a way that each new change gets harder and harder to make, until finally all progress stops. The most fun work I've done is maintenance programming where each change is easier than the previous one because each change improves the code base.
In your perfect little CLI world, the computer wouldn't nearly have the adoption rate as it does now. That means the industry as a whole doesn't grow. As such, we wouldn't have had the advancements in hardware that we enjoy today. The fact is, while the CLI may be great for scripted routines and vertical market solutions, it sucks absolute balls at scalability in feature sets. Not the CLI itself, but the learning curve. Also, having to pipe out a fucking paragraph just to get shit done is out-of-the-question for most people.
How do you know this, when almost noone -- except us current Unix users -- have even had a chance to try a decent CLI? Or any of the other successful Unix paradigms, for that matter.
To add to the confusion, mixing the CLI as the primary interface shell and non-standard application GUIs is even worse.
I guess you're referring to the pre-Gnome, pre-KDE X11 environment. I don't know -- I can see a revival for that simple model. Sure, Emacs doesn't have the same look & feel as xedit, but at least they aren't trying to control you or your system.
In fact, I'm not sure what Gnome or KDE or what's-it-name has to offer that is useful to me. I have a root menu, a simple window manager, and an xclock in a corner. What am I missing which needs to be integrated and centrally controlled by some project?
Although most likely true, this just goes to show that adjectives follow fashion and fall out of favor.
The bible of software engineering algorithms?--The Art of Computer Programming (vol. 1-4) by Donald Knuth. I'm pretty sure that the humble Knuth wouldn't have a problem describing himself as a Programmer.
Knuth also wrote (in an interview somewhere?) about how one interesting aspect of a programmer's work is the jumping between abstraction levels. One minute you're at the machine language level -- the other you're thinking of overall design, or usability. And of course that's what he did when he created TeX.
BTW, I'm sitting with a Debian Linux machine typing this. I wonder how they divided the work when writing ls, vi and awk? Or the other gigabytes of excellent free software in the Debian archive?
Comments above show this paper does not study what it purports to study and draws false conclusions based on a non-understanding of statistics. Is it my imagination or are we getting more and more crap papers like this on /.?
It's so boring listening to little Perl haters. They always seem to have some chip on their shoulder as if Perl were the one language they just couldn't ever get. As if that C++ is any fun. Please, *must* I write in C++?
Now that you mention it, it's also boring to listening to the C++ haters ...
I use perl for my daily tasks (scripts etc) at work and this "forgiving syntax" has been a time saver.. imho perl is (or should be) just an administrator's tool, nothing more.
That's absurd -- why should I as a normal user not use Perl for such daily tasks? Programming is not just for admins and big software development projects.
"It seems they're more eager to put out things and see what sticks" I guess he's not aware that this is Google's standard mode of operation as a business. Does this man live in a box, developing a browser nobody needs?
Perhaps he's questioning Google's standard mode of operation as a business? Did that occur to you?
Opera's Haakon Wium Lie On CSS, Web Standards, and More
A standard norwegian word, pronounced lee-ah. Please move aloing.
In my opinion the biggest problem with TCP/IP is that TCP is a stream protocol. Everyone who uses it immediately creates some sort of scheme to divide the stream into messages.
Yeah -- but dividing it in a way which suits the problem they want to solve. I'm not at all convinced that it's feasible to design a simple and safe "one size fits all" reliable datagram protocol.
And I'm very unimpressed by the UDP-based protocols I've seen: slow, fragile, constant problems with a fast sender overloading a slow receiver, inefficient stack--application interfaces ...
Because updating DNS zone files is a "exceptional circumstance" for an admin?
It seems to me that admins are in the tiny minority who can say s/\./:/g ...
> The netbook Amiga will set a mark in computer history as the first portable Amiga to see the light of the day since the Amiga 1000 was introduced to the U.S. market in 1985.
This sentence is confusing. Is it trying to say that the A1000 was portable? Because I had one and I can assure you that it was not.
No, that's not what the article was trying to say. It's just a funny way of sneaking in the name and birth year of the first Amiga.