Running Solaris on X86 is like going back in time to the 1980s with all the ancient Unix utilities -- it's got the ancient vi, not VIM, which is annoying when you need things like multiple undo or multiple windows. The awk/nawk are ancient, and it doesn't ship with perl (last time I checked). Ditto for most of the Unix shell programs.
The first thing I do when I get a Solaris system is to install a whole heap of GNU utilities, all of which come with any of the Linux distribution.
Neither BA nor Air France ever published financial numbers on just their Concorde service, but it was widely thought that even at $6k per ticket (and that's one-way!), Concorde lost money. These airlines subsidized Concorde as a status symbol.
So, I've got perl scripts which may need to work on Unicode and non-ascii character sets somtime in the future. Today, I just test them with UTF-8, and it seems to work, but who knows if they really do work on those funny character sets? I can't read Kanji or other non-ascii characters. How can I test to see if they do work? Ideally, I'd like to have an xterm-like window that uses my standard keyboard to generate analogs to all my ASCII characters, but with some test encoding that puts them into some 16 bit character set range. This way, I can make sure that since we've gone to all this work to add Unicode support into our scripting languages that it does indeed work. Does anyone know how to test this?
I've seen several references in the past to a chorded key device (scroll down) roughly the shape of an egg, which fits in your fist. It uses chords (multiple keys down at the same time), so that with just four or five keys in each hand, you can input a whole keyboards worth.
As usual with things like this (and dvorak keyboards), it takes a while to learn, but once you do, you can type pretty fast. Also, it would take up a lot less room, and be much less intrusive than even the smallest "standard" keyboard.
The cases won't be made of liquid water, rather the motherboards will be encased in ice sculptures. By the time the ice melts, you'll need to upgrade CPUs anyway.
Oddly enough, Microsoft is making it rather hard for third party developers to develop.NET applications, at least those that aren't only for in-house use. The.NET CLR does not yet come with any version of Windows -- you have to download the 25mb runtime yourself. There's still lots of dialup-speed users out there, and there's no way they are going to download a 25mb runtime just to run your app. I bet there's a lot of broadband users who would look askance at such a large download.
Until.NET is installed on enough desktops, it is going to be difficult to justify developing distributeable applications with it.
The NYT ran an article about this a while back -- they interviewed people who didn't want to buy things from unsolicited phone calls, but ended up doing so anyways, because they "felt sorry" for the person making the phone call. One woman they interviewed bought 5 $1k replacement windows, which she later admitted, "probably wasn't a good idea". She also said that she would sign up for a do not call list, to prevent her from mercy purchases in the future.
Don't think that the telemarketters don't know their own business.
125 Mhz MIPS CPU is fast enough to do some interesting things, but the box only has 16 Mb of RAM, and no local disk for paging. That's going to be the limiting factor for most of the fun things you'd like to do with this box.
This German court has ordered the German division of SCO to stop making these claims. But what if the North American parent company continues making the claims? Is SCO Germany still liable?
I've seen networks with effective firewalls still just down by worms. Laptops are a very effective way to breach firewalls -- if a laptop user connects at home, or on the road without a firewall, and gets the worm, it is trivial to bring that same computer into work, and start spreading it behind the firewall.
The clauses about 16 bitness refer to the source code, not what you can do with it. That is, all of the Unix source code for the PDP-11 is free to do with what you will, including make derivate works for 32 or 64 bit systems (as if!). The later System III and System V code is not under this license, though, and remain proprietary.
Your web browser probably wasn't implemented by people following the unix philosophy.
The Unix GUI environment doesn't support small tools as well as the command line environment.
GCC is GNU software. GNU software does not follow the unix philosophy. GNU software follows the add a command line option for everything and the kitchen sink philosophy.
This is exactly my point. There are many web browsers out there, and not one is built from program components connected linearly via pipes. Is this because everyone building a web browser is an idiot who just doesn't understand this magical Unix Philosophy? Or is it because this design strategy of small commands interconnected by linear pipes does not scale to the implementation of modern, large programs?
Ditto for compilers. A compiler is a very common, useful, complicated tool, and of the hundreds I've used (GNU or otherwise), not one has been implemented by a set of small programs interconnected by pipes. I've never seen a register allocator connected to an interference graph calculator connected to a register spiller, etc. etc. Every single compiler is a monolithic application, whether written by the GNU project or not.
Qmail is a great example of the Unix philosophy. It is a large, powerful system built with many smaller programs which do one thing well, and communicate via pipes (or the filesystem). I'm not familiar with cbb. But Qmail is almost the exception that proves the rule -- I can't think of any other large application that is built with this Unix philosophy, almost every other is one big program with IPC done via function calls.
Your post sounds a lot like Miguel's 'Unix sucks' talk where he explains that Unix does not (or did not) have much reusable code and components at a level finer than whole processes
Indeed. But this isn't an accident -- The Unix Philosophy (such as it is), is that the level of granularity of a resuable component is a process, connected via a pipe.
Interestingly, I recently attended a lecture by a Plan 9 luminary who railed against shared libraries. His view is that there should be no shared libraries, rather separate processes and IPC. Therefore, there should be no MIME parsing library, rather one program running which can be asked to parse MIME, and returns the parsed results. The removes some of the limitations of pipes, but keeps the "process as atomic unit of reusability". I'm not sure how that's going to play out in real life.
I use pipes all the time, but this is what I was trying to say in my initial post -- pipes are very handy for day-to-day things. But, the Unix philosophy is that pipes and small programs are suitable to build large applications. And we just don't see that.
I've been using Unix for 20 years, and can write some mean shell scripts. I've read all the original papers which talk about how great it is to have many small tools and little languages which you can hook up via pipes. That sounds great on paper, but I've never really seen it work out in practice.
Sure, we've all writing massively pipeline shell one-liners to do day-to-day tasks, but these are just one-time, throw-away code. All of my real Unix apps that I use every day are huge monolithic applications, not a composition of many tiny apps connected by pipes. My web browser is a monolithic app, not connected by pipes. GCC is a couple of monolithic applications, optionally connected by pipes, but never reconnected in any useful way (cpp notwithstanding). My newsreader and mailreader again, monolithic applications. My MTA, again, a monolithic application. Not one large program I use is a shell script, or collection of small, interchangeable programs.
So, is this Unix tool philosophy useful for real applications, or just for little shell scripts?
If you could somehow get a 1 percent phone reply rate, the spammers would drown -- the current reply rates are something like 1 in 10,000. With a one percent bogus reply rate, there would be 100 bogus responses for every good one.
That could be effective, if the spamvertised product or service requires some human time or money to process. Mortgages, for example. If each mortage application that looks remotely serious takes 30 minutes of some human's time to process, a relatively low bogus reply rate could swamp them, and make it unprofitable.
If there is no time or money required to process the orders (for example, some medicinal product the spammer never intended to send anyway), then a high bogus return rate won't make a difference.
So, the log has 6000 responses, with credit card info. I wonder how many of those 6000 are real, and how many are bogus or stolen credit card numbers from pissed-off spamees?
Too many people seem to have either forgotten this or choose to ignore it. 'Cathederal style open source' is a common reality
Exactly. But the OpenGroup's charter, to develop open standards, is inherently Cathedral-y. To take Motif as an example, just open sourcing it, and maintaining it in a Cathedral way isn't going to help any. What role could the OpenGroup have in a bazaar world?
Both Gnome and KDE were able to leverage the design work that went into Motif and the other widget sets that came before them. Motif was better than Athena for the same reason. Most of the hard work goes into the design.
Can you cite an example, as I don't think this is true. Motif sits atop of libXt, which turned out to be a huge mistake in retrospect. Neither KDE/QT nor Gnome use the X toolkit. QT was designed to work with a preprocessed C++, whereas Motif is pure C.
The real reason that Motif is better than the Athena widgets is that a lot more people worked on Motif than Athena. An even greater amount of resources are put into both Gnome and KDE. A big part of this is the bazaar approach, which they both use.
The Open Group has been pretty much irrelevant for the last 5 years, not because they have been closed source, but because they are a Cathedral style closed source. Both Gnome and KDE have become far, far superior to Motif in a far shorter amount of time. What role is there to play for a centralized standards-blessing body in the world of the distributed, bazaar-style development?
Slashdot Mirror
The first thing I do when I get a Solaris system is to install a whole heap of GNU utilities, all of which come with any of the Linux distribution.
Neither BA nor Air France ever published financial numbers on just their Concorde service, but it was widely thought that even at $6k per ticket (and that's one-way!), Concorde lost money. These airlines subsidized Concorde as a status symbol.
So, I've got perl scripts which may need to work on Unicode and non-ascii character sets somtime in the future. Today, I just test them with UTF-8, and it seems to work, but who knows if they really do work on those funny character sets? I can't read Kanji or other non-ascii characters. How can I test to see if they do work? Ideally, I'd like to have an xterm-like window that uses my standard keyboard to generate analogs to all my ASCII characters, but with some test encoding that puts them into some 16 bit character set range. This way, I can make sure that since we've gone to all this work to add Unicode support into our scripting languages that it does indeed work. Does anyone know how to test this?
And how much bandwidth can a spammer consume in 60 seconds? Be sure to take bouncing, email list expansion and mail forwarding into account.
As usual with things like this (and dvorak keyboards), it takes a while to learn, but once you do, you can type pretty fast. Also, it would take up a lot less room, and be much less intrusive than even the smallest "standard" keyboard.
The cases won't be made of liquid water, rather the motherboards will be encased in ice sculptures. By the time the ice melts, you'll need to upgrade CPUs anyway.
Until .NET is installed on enough desktops, it is going to be difficult to justify developing distributeable applications with it.
Don't think that the telemarketters don't know their own business.
125 Mhz MIPS CPU is fast enough to do some interesting things, but the box only has 16 Mb of RAM, and no local disk for paging. That's going to be the limiting factor for most of the fun things you'd like to do with this box.
So, if sco.de links to sco.com press releases, is sco.de still making claims?
This German court has ordered the German division of SCO to stop making these claims. But what if the North American parent company continues making the claims? Is SCO Germany still liable?
I've seen networks with effective firewalls still just down by worms. Laptops are a very effective way to breach firewalls -- if a laptop user connects at home, or on the road without a firewall, and gets the worm, it is trivial to bring that same computer into work, and start spreading it behind the firewall.
The clauses about 16 bitness refer to the source code, not what you can do with it. That is, all of the Unix source code for the PDP-11 is free to do with what you will, including make derivate works for 32 or 64 bit systems (as if!). The later System III and System V code is not under this license, though, and remain proprietary.
The Unix GUI environment doesn't support small tools as well as the command line environment.
GCC is GNU software. GNU software does not follow the unix philosophy. GNU software follows the add a command line option for everything and the kitchen sink philosophy.
This is exactly my point. There are many web browsers out there, and not one is built from program components connected linearly via pipes. Is this because everyone building a web browser is an idiot who just doesn't understand this magical Unix Philosophy? Or is it because this design strategy of small commands interconnected by linear pipes does not scale to the implementation of modern, large programs?
Ditto for compilers. A compiler is a very common, useful, complicated tool, and of the hundreds I've used (GNU or otherwise), not one has been implemented by a set of small programs interconnected by pipes. I've never seen a register allocator connected to an interference graph calculator connected to a register spiller, etc. etc. Every single compiler is a monolithic application, whether written by the GNU project or not.
What bash, perl and awk scripts did you use to post this comment with?
Qmail is a great example of the Unix philosophy. It is a large, powerful system built with many smaller programs which do one thing well, and communicate via pipes (or the filesystem). I'm not familiar with cbb. But Qmail is almost the exception that proves the rule -- I can't think of any other large application that is built with this Unix philosophy, almost every other is one big program with IPC done via function calls.
Indeed. But this isn't an accident -- The Unix Philosophy (such as it is), is that the level of granularity of a resuable component is a process, connected via a pipe.
Interestingly, I recently attended a lecture by a Plan 9 luminary who railed against shared libraries. His view is that there should be no shared libraries, rather separate processes and IPC. Therefore, there should be no MIME parsing library, rather one program running which can be asked to parse MIME, and returns the parsed results. The removes some of the limitations of pipes, but keeps the "process as atomic unit of reusability". I'm not sure how that's going to play out in real life.
I use pipes all the time, but this is what I was trying to say in my initial post -- pipes are very handy for day-to-day things. But, the Unix philosophy is that pipes and small programs are suitable to build large applications. And we just don't see that.
Sure, we've all writing massively pipeline shell one-liners to do day-to-day tasks, but these are just one-time, throw-away code. All of my real Unix apps that I use every day are huge monolithic applications, not a composition of many tiny apps connected by pipes. My web browser is a monolithic app, not connected by pipes. GCC is a couple of monolithic applications, optionally connected by pipes, but never reconnected in any useful way (cpp notwithstanding). My newsreader and mailreader again, monolithic applications. My MTA, again, a monolithic application. Not one large program I use is a shell script, or collection of small, interchangeable programs.
So, is this Unix tool philosophy useful for real applications, or just for little shell scripts?
That could be effective, if the spamvertised product or service requires some human time or money to process. Mortgages, for example. If each mortage application that looks remotely serious takes 30 minutes of some human's time to process, a relatively low bogus reply rate could swamp them, and make it unprofitable.
If there is no time or money required to process the orders (for example, some medicinal product the spammer never intended to send anyway), then a high bogus return rate won't make a difference.
So, the log has 6000 responses, with credit card info. I wonder how many of those 6000 are real, and how many are bogus or stolen credit card numbers from pissed-off spamees?
Exactly. But the OpenGroup's charter, to develop open standards, is inherently Cathedral-y. To take Motif as an example, just open sourcing it, and maintaining it in a Cathedral way isn't going to help any. What role could the OpenGroup have in a bazaar world?
Can you cite an example, as I don't think this is true. Motif sits atop of libXt, which turned out to be a huge mistake in retrospect. Neither KDE/QT nor Gnome use the X toolkit. QT was designed to work with a preprocessed C++, whereas Motif is pure C.
The real reason that Motif is better than the Athena widgets is that a lot more people worked on Motif than Athena. An even greater amount of resources are put into both Gnome and KDE. A big part of this is the bazaar approach, which they both use.
The Open Group has been pretty much irrelevant for the last 5 years, not because they have been closed source, but because they are a Cathedral style closed source. Both Gnome and KDE have become far, far superior to Motif in a far shorter amount of time. What role is there to play for a centralized standards-blessing body in the world of the distributed, bazaar-style development?