> When you tell Bob you like his pink flannel shirt, are you lying? > [...] People who don't lie at the right times are called "assholes".
The idea that you have a choice between lying and maliciously making Bob feel like a loser who can't dress himself is a false dichotomy. It's hard for geeks, I know, because I have a good deal of trouble with it myself, but there's this thing called tact: the ability to tell the truth without stirring up unnecessary trouble. If Bob's new visible-from-space pink-and-orange shirt makes you want to pulk, telling him you think it's "simply wonderful" is a lie. Telling him it makes you want to pulk is tactless and needlessly provocative. Tactful is something along the lines of, "Actually, I rather like the blue shirt you wore the other day." This is difficult to do on the spot, sometimes, granted. Especially for people like me who are highly unlikely to have *any* idea what the person wore yesterday, the day before, or ever. (Heck, I don't remember what *I* wore yesterday.) Another possible mostly-tactful response would be, "Oh, Bob, I'm not the one to ask about fashion stuff. I'm no good at that sort of thing."
I once managed to tell a 40-year-old female coworker who had just had her hair cut short and asked how we all liked it that I _didn't_ particularly like it, without hurting her feelings. I told her that I had liked it better the other way. As it turned out, it just happened that she wasn't really happy with the cut herself, but with everyone saying how much they liked it she wasn't going to admit that until someone else said otherwise. Maybe I just got lucky? Maybe. Or maybe there's something to be said for tact.
Language Diversity rules. However, a really good language ought to be designed so that you can use diverse programming paradigms within the limits of that language. Perl is taking some steps along these lines. Perl5 already has very good support for procedural programming, basic functional programming, basic contextual programming, and with a little work you can get it to do basic OO programming also. Perl6 is revamping the OO stuff to be a first-class citizen, as well as bolstering the contextual and functional stuff too. (There's even talk of continuations and lazy evaluation.) There is also talk of adding support for logical programming (a la prolog), but I don't know whether that's really going to happen.
There's still work to do, of course. Perl6 is a long way from being ready. But the list of languages that have influenced its design is *lengthy*. Right now, there are things I can do in elisp or Inform easier than in Perl5. The object model coming in Perl6 will shorten that list to just elisp, and it will be possible to implement textbuffers using the Perl6 object model; if someone (such as myself -- I'm seriously thinking about it) does so and puts it on CPAN, then I won't need elisp either, except for customizing Emacs.
So now I'm learning Scheme, which has some *more* things Perl5 doesn't have, such as continuations -- but word has it these things are going to be in Perl6, so I figure I'll get a leg up on the concepts by understanding them in Scheme now.
Hopefully, multiparadigmatic VHLLs such as Perl, Python, and so forth will utterly take over, eventually, except for extreme low-level stuff like bootloaders and device drivers. For that to happen, we'll probably need optimizing compilers for these languages, or a really good, ubiquitous VM. (Parrot hopes to be the latter. We'll see how that goes. The Java VM is almost ubiquitous enough, but it's not good enough, and none of the VHLLs target it AFAIK (presumably because it's designed especially for Java).)
> dude, if I had to look at a desktop like that the whole day, I would also > get unusually sensitive eyes, as well as some serious other accessibility > requirements, primarily in the mental area....
Yeah, none of my coworkers like it either. "Why don't you use some more interesting colors?" "Like what", I ask. "Oh, I don't know, white?"
I seriously don't understand the obsession that the rest of the world has with color settings that make you go snowblind in two minutes flat. I know, lots and lots of people like it that way. Not me. I prefer *not* to have to wear sunglasses to use my computer, thanks. Actually, that's the good thing about my colors: I can look at them for twelve hours without getting eyestrain. "Normal", black-on-white color schemes make me have to close my eyes for a couple of minutes every little bit, and after a five hour shift I need to lay down in a dark room with my eyes closed and sleep off a headache. I have almost all of the computers at work (all the ones I have to work with with any frequency) set so that the "light" background color for windows is more like #CCCCCC instead of #FFFFFF, so that I don't go blind every time I have to do anything with them. Still, after a few minutes I need to get away from that screen, back to my nice calm tertiary color scheme.
Of course, I also have a black trashbag taped over the window in my bedroom, and I don't like to be outside in the daytime... so I guess my eyes are a bit more sensitive to light than average. I can read by the light of a single votive candle on the other side of the room without difficulty. I also see much better than average in the dark. The only place I've ever been where it was too dark for me to see effectively was in Mammoth Cave when they turned out the lights to demonstrate actual factual darkness.
> Am I not as capable of having fun as I once was, or what?
Maybe your ideas about what is "fun" are changing. This in itself is not a bad thing. When you were eight, you probably thought it was fun to run around on a blacktop with eight-year-old children. At some point you may have thought it was tremendous fun to read those lame, elementary-school joke books, such as "101 Fun Food Jokes". Think that's fun now, do you?
The first time I ever played a 3D FPS (it was Wolfenstein 3D at the time), I thought it was pretty cool. At this point, I've had a belly full of those and don't care if I never see another one.
Here's one of mine, which demonstrates an unusual accessibility requirement (the
soft tertiary colors -- my eyes are unusally sensitive to light; I CANNOT
handle Evil Blinding Backgrounds or high contrast). It also demonstrates the
left side panel full of launchers, drawers, and applets that I've grown to
love. The only things on the bottom panel are the task list and the clock.
If it matters, this is a Mandrake 9.2 system with Gnome (but I replaced
Metacity with Sawfish (because I want features, darnit) and replaced Nautilus
with nothing (because I do all my file management from the command line)).
The top drawer (with the drawer icon) holds the foot menu and launchers for
assorted utilities and configuration things. The next drawer down, the one
with the gnome-terminal icon, holds launchers for gnome-terminal (with
various terminal classes and commands -- e.g., one for MySQL, one that does
ssh into the cgi server, one that does ssh into the router, and so on).
The drawer below that holds launchers for browsers. Then you've got three
launchers right on the panel because I use them a lot: OO, Gimp, Emacs.
Below the blank space is the screenshot button, the run button, a drawer
of audio stuff, a drawer of games, the show desktop button (which really
I ought to remove; I never use it), the CPU, memory, and swap meters, and
the log out button at the bottom, out of the way. (Does anyone else think
the Gnome1 logout icon looked nicer, or is that just me?)
That Mozilla window has been open for some while; the first two tabs in
particular have been open for a couple of weeks. This is typical.
One of the Emacs windows has eshell, which is running a telnet connection
to the im2 multiplexer for the Perlmonks.org chatterbox. Another is Gnus.
The third has open the Changes file for Net::Server::POP3, which is what I
really ought to be working on instead of posting to slashdot.
Be sure to get a screenshot showing gdmflexiserver running with the
Xnest option. That's a really cool feature.
For bonus points, have a different desktop environment running inside
the Xnest window than the one running outside it.
Also try to get a shot
from someone who uses ratpoison; there's no window manager more
minimalist than that, especially when it comes to window decorations.
Be certain to show off several interesting panel applets, especially
if you can get one running in a tiny always-on-top panel. Get one
showing something really cool being worked on in Gimp, too. And be
sure to get an Enlightenment screenshot showing that weird dragbar
thing about halfway up/down the screen. I don't personally like that,
but it's innovative and different, and some people swear by it.
> > I tried to learn PHP, but I got really tired of reading about how > > much "better" PHP is than Perl because it's Not CGI(TM). > > Care to point out where the PHP documentation states that? Or are you > just judging the language by a vocal minority of its users?
Huh. It appears to be *gone*. It was there, honest. I googled for PHP, went to the first result that wasn't a paid advert, and clicked on a link that said something like "tutorial" or "documentation". This was a little while ago, though (at least a year).
Still, the manual at http://www.php.net/manual/en/index.php seems to me to be a revision of the same documentation I was reading. A lot of the wording in it is very very familiar to me, so I'm almost sure it's the same document (or the one I saw copied from this one, or vice versa, or something). However, all that negative CGI-bashing is *gone*, as if someone has edited the document ad interim and cleaned all that junk out.
So, um, ignore my ranting; this issue appears to have already been fixed, and I'm just behind the times. There's nothing to see here; move along.
> Only and the biggest problem with Win-Live CD is that YOU CAN'T PATCH IT!
That's no big deal; you don't patch a Live CD anyway; there's no point. You just get the latest version.
I would expect the *big* problems with a Windows Live CD to be in terms of hardware support and the expectations of applications. With regard to the former, Microsoft has for a LONG time now relied on the hardware manufacturers to supply almost all of the drivers. It is almost impossible to build a complete system entirely out of hardware that will work with Windows without installing manufacturer drivers. Microsoft (or whoever was licensing Windows to produce the Live CD) would have to license all the drivers from the vendors of the hardware. No individual driver would be a problem (vendors would want their product to work with the Windows Live CD), but there are a *lot* of them, and tracking down agreements for all of them would be a significant pain. I would expect such a project to take at least a year.
The other problem is worse. LOTS of applications won't run on Windows XP unless you log in as a user with Administrator privileges. (This is *one* of the reasons OEMs all ship with a passwordless Owner account and no non-privileged user accounts.) There are assorted reasons why apps don't work without Admin privs, but mostly it boils down to their having been designed, a couple of versions ago, for Windows 98, where that stuff just doesn't matter. Judging by the number of applications still in use today that do various highly-deprecated things (use the DOS API, require to be installed in C:\APPNAME, store the user's documents in the application's directory under Progra~1, and assorted other schenanighans along the same lines) it seems unlikely that the apps will all be capable of running in a tightly controlled environment any time soon. Of course, I'm mostly not talking here about general-purpose apps like word processors, but more in terms of field-specific custom stuff, like library automation software, hospital software, accounting software, and so on. The general-purpose apps are mostly somewhat better behaved, and so for scenerios where nothing very special is needed the bootable Windows Live CD might be practical within a few years. I won't be holding my breath though.
Heck, I'd be happy just to have a bootable Windows CD that's usable as a rescue system. Something along the lines of Knoppix but with regedit and other Windows-specific things. If it would run on all the hardware Knoppix runs on, I'd be ecstatic. If I could afford the thing, that is. Windows really ought to ship with such a thing in the box. Well, the Pro edition should, anyway.
Are they rewriting the docs to actually explain the features of the language and how to use them? I tried to learn PHP, but I got really tired of reading about how much "better" PHP is than Perl because it's Not CGI(TM). Come on, stop *saying* it's better and *show* me it's any good. What features does the language have? How would I go about using them? If PHP is so good, the docs ought to be able to convince me of that without endlessly repeating it.
I also got tired of seeing what ought to have been one-liners written in fifteen or twenty lines of PHP. Is the language really that needlessly verbose, or are those just bad examples?
In summary, the documentation is so bad, I can't even make a decent evaluation of whether the language is any good. The *first* thing the PHP crowd needs to fix is the documentation. It ought to be rewritten from scratch.
> I've seen somebody tring to do cross-tab reports in a single step in SQL > (I think it was based on a query in Joe Celko's SQL for Smarties book). > It worked fine with a few hundred to a couple of thousand rows of data > (less than 5 secs), but by the time it had grown to only 10,000 rows, the > query would take more than an hour. This is the same machine that runs some > other simpler queries against a 250 million row table in under 15 secs. The > point being that a simpler version of the query would run in a few seconds, > and then Excel could do the cross-tabulation with copy-and-pasted data for > total of 5 minutes extra effort.
Excel isn't the only (or even necessarily the best) tool for this sort of thing. I've often found myself doing an SQL query via DBI, then filtering the list of record hashrefs with Perl's "grep" list transform operator. But your point generally is a good one: sometimes it's faster to use a simple query to fetch a bunch of data and then filter it, rather than using a complex query to fetch exactly the right data. This also applies more broadly than database stuff. Just a couple of weeks ago I was writing a simple script that automates the process of doing something (I forget what) on the web, using WWW::Mechanize, and it needed to extract a certain element from the page. Rather than trying to extract just the one needed element, it was easier to use HTML::Tree and look_down to extract all the elements of the right type (td IIRC) and then grep the list for the one in question.
> Do you do your own fillings too, instead of going to the dentist? > You hire me (a profrssional database programmer) to write a database
I don't do my own fillings, but I do brush my own teeth. We're talking about *simple* databases here. One table. Five or six fields. Fifty records. The kind of stuff people do in Access, or even in the database portion of Microsoft Works (as of version 4, anyway; not sure if the current version of Works still has that). Hiring a DBA for this stuff would be like paying a CPA to fill out my 1040EZ. (Yes, there *are* people who do that...) More than 99% of all the world's databases are tiny little one-table things like this. We've got eight or nine of them where I work, and about ten full-time staff, plus several students who work part-time, a maintenance guy and a cleaning lady, for a grand total of maybe twice as many employees as one-table databases. None of these databases have more than nine or ten fields, and none of them have more than a couple of hundred records. This seems to be typical; when I was in college, the professor I worked for had half a dozen databases very similar to this. At the time he was in the process of switching them from MS Works to Access. He was also in the process of migrating documents from WordPerfect 5.1 to Word 6. (Stop looking at me like I'm some kind of geezer. It wasn't *that* long ago.)
That said, I do this stuff in MySQL and set up a Perl CGI frontend. I think I'm a bit more of a poweruser than the average Access user though. It'll be good when OpenOffice has a database frontend. (This is in the works, but it's not ready for end users yet.)
There are a couple of problems with doing these one-table databases in a spreadsheet, but the most obvious is that the user can't just click on a field title to sort by that field. Also, there are no advantages to the spreadsheet approach. I've used that approach in the past, but I don't favor it. The one-table database is better for this. Spreadsheets are for keeping your checkbook and stuff like that, where you have a lot of calculated cells, and the stuff on one line is derived partly from the previous line. If the lines have no particular order, or might need to be sorted in one of several orders (by different columns), a database is the way to go, even if it's a tiny little one-table database with columns for "name", "address", "phone", "year joined", "paid thru", and "notes".
> MS access took me far longer as it was not entirely conforming to > open standards (i.e. SQL)
Nothing conforms to the open SQL standard. Get the SQL in a Nutshell book, and start comparing SQL99 to the various implementations. MySQL is nowhere near conforming. PostgreSQL is a little better, but far from perfect. MS SQL Server and Oracle both deviate too.
I'm all for standards, but the SQL standard is still waiting for even one conforming implementation, as far as I know.
That said, I also spent more time trying to figure out Access than I spent learning the basics of MySQL. However, I had a book (the abovementioned one) for learning MySQL, and when I was messing with Access I had only the help files. Also, that was a while ago, a version of Access that would now be considered horribly obsolete. (It ran on Windows 3.1...) For all I know the current version of Access may be better. (Or it may not; I wouldn't know, as I've not seen it. The regular version of Office doesn't even include it anymore.)
Also, I cut my teeth on PC-DOS 3.3, so I'm comfortable with command-line interfaces. People whose first computer ran Windows 95 might have a harder time learning to use MySQL (though there is that mysqlcc thingy; I've barely experimented with that at all, so I won't comment further).
You can access Access databases from Perl, using the DBI, so I don't imagine there's anything in particular stopping OpenOffice from supporting it too, except that the OO.o database frontend thingy isn't really ready for end users yet. (IBM could put a couple of programmers on the project and fix that in a few months, if they wanted to take that route.)
I think it's more about IBM not wanting to switch people over to OpenOffice for training reasons. OpenOffice is great, but it is different from MS Office. At work we have two computers with MS Office, and every time someone asks me a question about it I hunt around in Help for the answer, get frustrated, open the document in OpenOffice, and solve their problem there -- because OpenOffice is what I have at home, what I have on my desktop at work, and what I know -- and Microsoft Office is different. If you were going the other direction, you would probably have the same issues. So that's why IBM wants MS Office -- it's what their customers are currently using, and they don't want to retrain them.
> I would love to use a C/C++/Java-like language that utilizes pure objects
If it had a good object system, wouldn't that make it totally unlike C, C++, or Java? At least, semantically it would. I suppose the syntax could be C-like. Inform for example has C-like syntax, but the object system is so much more advanced than the one used by C++ that there is no comparison. (Inform, however, is not a general-purpose language. It doesn't have the I/O capabilities to be general-purpose. This is mostly due to the virtual machine it's designed to compile to, which for portability reasons doesn't support such things as a filesystem per se. But it's a great language for its intended problem space.)
> FORTRAN is highly counter-intuitive, but it's a damn fast number crunching > language (rivaled only by C, if I remember my benchmarks correctly).
FORTRAN is more than merely *rivaled* by C; when it comes to being highly counter-intuitive, FORTRAN is utterly *outclassed* by C.
Oh, you meant rivaled in terms of the speed of number cruching? Then, yeah, as long as the numbers in question are small enough to be represented by C data types. Otherwise, it's best to stick with FORTRAN for that.
(Please note that I'm not advocating FORTRAN for things *other* than number crunching. It's utterly worthless for text handling, for example. For that you use Perl.)
> I'm not suggesting that we do away with basic arithmetic or variable > assignment. You can't do that and still have a programming language.
Well, you *can*... unlambda for example doesn't have *anything* like variable assignment, nor does it directly include any arithmetic primitives (though it is possible to do arithmetic indirectly).
> The very idea [...] is just plain silly.
I think unlambda is more scary than silly.
> You just can't 'fix' bad programmers with better languages.
No, of course not. You can remove certain very common and problematic classes of bugs, though, such as buffer overflows, segfaults, and memory leaks. But there will always be application-specific logic bugs, and there are classes of common bugs (e.g., infinite loops) that cannot be easily solved at the language level (except by crippling the language, which is unuseful).
Agreed. I love Perl to death, but the OO sucks rocks. (But then, I don't like the OO in C++ any better. I guess Inform's wonderful object system has be spoiled.) This is getting fixed in Perl6, but of course that's all in the future at this point. (We haven't even got the Apocalypse article on objects yet, though we've got quite a lot of information about them already from the previous articles.)
The thing I like about Perl the most is the multiparadigmatic approach. (Well, that and the CPAN. CPAN rules. It's like sourceforge and portage all rolled into one, plus better documentation and better searching facilities.) What do I mean by "multiparadigmatic approach"? I mean, I can use freely interleave functional, object, imperative, and contextual styles, using whatever best fits the problem I'm solving. If it suits my purposes, I can have a global array of hashrefs, and each hash can hold several closures that share between them (within that hash, but separate from the others) an object (say, a DBI handle). Or, if it suits my purposes better, I can have a class of objects that each retain as one of their properties a closure that holds a private array of helper objects -- and that's just using the major traditional paradigms (object, functional, and imperative). Perl also has the contextual paradigm, which once you get the hang of it is incredibly useful.
And yeah, when I read this slashdot blurb... > First, making software more 'intuitive' for developers will reduce bugs. > Second, software should more closely simulate the real world, so we should > be expanding the pure object-oriented paradigm to allow for a richer set > of basic abstractions -- like processes and conditions.
I immediately thought, "Oh, in other words we should use Perl, or something a heck of a lot like Perl."
> I prefer C/C++ because things are pretty explicit, ie. you need to define > your variables explicitly before you use them
You can fix this in Perl. Just put the following line at the top of each file: use strict;
> However, with Perl, there are so many things that if they aren't present, > they are assumed. It is very "hacky" and makes it very hard to read.
Only when you're very new to the language. Once you've learned it, the terseness makes it possible to see whole functions -- indeed, whole entire algorithms -- on the screen at one time in a clear, easy-to-follow layout. (Pay no attention to my signature; that's that way on purpose, and if you think C is immune to obfuscation, google for IOCCC sometime.)
Having all that superfluous redundant stuff written out just turns simple functions that ought to be ten lines (half of that comments) into multi-page monstrosities that require several minutes to read and understand. Bleah.
If you don't like Perl, try Python. It's more strict about a lot of stuff, so you might like it better, if you're into that sort of thing. However, it shares with Perl certain very critical features that every language ought to have, such as built-in memory management. (No more buffer overflows EVER:-)
Personally, I tried Python, didn't care for it, and went back to Perl.
Reiser would be harder to do, I think, than (say) ext2/ext3. The Reiser fs is designed to be a good filesystem, not to be easy to implement. (In that respect, it's somewhat like NTFS I think and nothing at all like FAT.)
Actually, in terms of a filesystem being easy to implement, nothing[1] tops plain old ordinary FAT. Even FAT with LFNs and such (vfat, that's sometimes called) isn't too bad. Nice and simple. Only problem is, there are too many things it doesn't support: journaling, file ownership, multiple sets of permissions for different classes of users,... it's a great fs for a multiboot user to use for storing stuff you want to be able to access from all your different OSes -- just have one partition that's dedicated to documents and other data that you want to be able to get to from any OS. However, FAT doesn't make such a good OS for installing an OS and applications on, for the reasons listed.
Anyway, writing lowlevel Windows software to let you mount ext2/3 filesystems would be an interesting and useful (albeit probably not easy) project, but it wouldn't help one iota in terms of letting you use Linux as a rescue system for doing repairs to Windows, nor would it let you access the data on a stock-out-of-the-box Windows system, so it's no substitute for real NTFS support. captive-NTFS will do for now (especially once the Knoppix version with it comes out), but it would be nice to have real native NTFS support.
[1] Nothing that's usable as a filesystem for a general-purpose OS, I mean.
Obviously you could have a super-simple filesystem that just treats the
whole disk as one big hogfile (DHF), for example, which would be easier
than a bubble sort to implement, but performance would be like sucking
gravel through a coffee stir, and there wouldn't be any robustness.
(scandisk or fsck? forget it; if you need to check the filesystem, you
probably need to reformat the part of the drive from the point of
corruption upward.) Also, no directories, and no long filenames...
> You, my friend, win for best line I have ever read on slashdot... > > IANAL, but from what I've read on slashdot... > This is good stuff
The wording was deliberately worded in such a way as to avoid giving anyone the impression that I was remotely certain about what I was saying. It was an idea that was running through my head, no more.
> Maybe they are taking some ideas from SCO on how to profit from the OSS > community.
SCO is profitting from investors (mainly two large ones), not from the OSS community. The OSS community is only involved as a way of generating some publicity. (It's a remarkably complex way to generate publicity, but that's what they're doing (quite successfully, I might add). The process is really too involved to classify as a "stunt", though, as that would imply a terminating sequence of simple events; SCO's publicity engine seems to be more of an ongoing thing.)
Microsoft doesn't *need* the OSS community to generate publicity; they can get media attention as easily as the President of the United States. And over the medium or long term they seem to be much better than SCO at making profit. So no, I don't think Microsoft is planning to pull a SCO for the purpose of generating revenue.
If they *were* planning a lawsuit (which seems unlikely; not that I'd put it past them, but the leak is more easily explained elsewise; various things seem to leak out of MS regularly, not all of which Microsoft wants released, I'm pretty sure; there's no reason to believe this is different) it would be for the purpose of squelching competition, not generating revenue directly.
> it'd sure be nice to have a way to get rid of [Outlook Express]
An easier way, I mean. What one has to go through to do it the way I know how is rediculous. Every new WinXP system we get I have to devote at least an hour to hunting down and removing all the MSOE components; it's a pain, but I'm not willing to support a network that has OE on it; that would be worse.
> people should realise that the NT kernel is actually an extremely sensibly > structured and well written system, it's just most of the peripheral junk > like IE that's bundled on top that leaves something to be desired.
I don't know exactly how sensibly-written the NT kernel is (other than that it's obviously *way* better than the Win9x kernel; that much is clear). I do know that certain apps bundled with it (most notably Outlook Express) are much worse than the mere waste that you mention[1] but more akin to poison, as they *actively* compromise security. (OE (or something) also actively takes measures to prevent you from removing it and/or restore it if you do, which as far as I'm concerned qualifies it as a virus.) So the kernel is certainly not the major problem with current NT systems. As near as I can tell, the kernel's not half bad, but some of the other components of the system are much worse than half bad. If you want to call Outlook Express "peripheral junk", sure, then I can agree with what you say, but it'd sure be nice to have a way to get rid of the peripheral junk. (And don't say "just don't use it"; I have to deploy to users who don't know the difference between My Computer and their ISP; they're sure not going to know whether they're using Outlook Express or not; I want it *removed* from the system, GONE.)
> I've been using my machine for 4 years with Win2k, and never got a virus > and never got exploited.
Yeah, I've been maintaining a network since 2000 April (not quite 4 years yet) that's currently got nine (about to be ten) Windows systems on it of one flavour or another (plus several macs, a couple of Mandrake systems, and one OpenVMS), and the last time we had anything that resembled a virus running on our systems was Bonzi Buddy which was already there when I was hired, and I cleaned it off sometime in 2000. (I say "running" because we did have a situation where a virus file got deposited on an exposed network share, but it never got executed on our systems and I got rid of it and moved the network share behind a NAT gateway (specifically, a headless Mandrake box doing IP Masquerade).) But I've accomplished this by making darn sure there are no MSIE shortcuts on the desktop or start menu, making sure MSOE (and in some cases Outlook -- we have a couple of systems with Office) is non-functional (which is much harder on XP than on Win98, I might note), having no working removable-media drives on certain systems (ones that are accessible to random persons and connected to the network), and other measures that really ought not to be necessary. Sure, it's *possible* to secure Windows systems, but it's entirely too much work. I've put almost no time into keeping the Mac systems secure and for the Linux systems I only had to upgrade server-type apps a handful of times; if they hadn't been running any server stuff (the Windows systems aren't), then they wouldn't have needed any maintenance at all (unless there were new features available in the new versions that I wanted, like Emacs 21, browser upgrades,... but that's not security maintenance).
My hatred is particularly strong for Outlook Express. I want it removed from the universe, sooner rather than later. (Today would be good. Yesterday would be better. Five years ago would be wonderful.) I don't even want people to remember it. *I* certainly won't want to remember it.
[1] You used a less-kind word for it. You know the stuff I mean.
If (and this is the sort of "if" that places us well more than a mere one leap away from reality) the WINE team had full legal access to the Windows source code granted them by Microsoft, the miracle version of WINE would definitely not come out "within a few weeks". The job of ingesting all that info and getting a feel for the organisational peculiarities of a codebase that large would impose a multi-month overhead before you could really even start to do meaningful work.
Actually, that's exactly what I was going to suggest, though not by copying. I was going to say the first thing anyone competent in C/C++ who gets their hands on the code ought to do (providing they don't need to take a hands-off approach due to, say, the need to be able to legally write competing OS code) would be to post English descriptions anonymously to usenet, describing the way NTFS works, especially the parts that are not currently well-understood. No source code snippets, just stuff like "it appears that such-and-such information about each file is stored and updated whenever it changes in three places: at offset blah in the file header info, and...". (I don't know beans about NTFS, so any fs jargon that leaked into that sentence may not be accurate. But you get the idea of the kind of thing I mean.)
Then somebody else could take that information and implement a compatible filesystem in a clean-room fashion.
IANAL, but from what I've read on slashdot, there's apparently at least a vague possibility the resulting code might be legal. Though, one should consult legal counsel before spending significant time on such a project.
> > When that happens, which will usually be sooner rather than later, the > > US ecconomy regains the twenty billion in GNP that it lost due to the > > oursourcing. > > Correct me if I'm wrong (which I am sure you will do), but isn't that > EXACTLY what I said that you disagreed with, saying economics doesn't > work that way?
I then went on to explain why it doesn't work that way, but apparently my explanation wasn't clear enough for you.
> Let's bring down your argument to a more human level
In other words, let's make an emotional plea instead of being rational, so we can get people excited about the starving children of the farmers, so they'll forget about the ecconomics of the situation. Try to remember that the depression was not caused by outsourcing jobs to the third world but by a sudden correction in the stock market, which had become greatly inflated in the previous years, due to not having enough smaller downward corrections.
> Tech workers today are out of a job because the companies found a cheaper > labor force, but when they try to find another job there are more candidates > than jobs so salaries go down and they are lucky to get a job at ANY wage.
You exaggerate. Greatly. We're not starving. Most of us aren't even completely without work. In fact, it's still a fairly decent field to be in, on the whole. Tech workers have just experienced for the first time what workers in other industries have known about for centuries: a labor surplus. This is not mostly the result of outsourcing (though that can aggravate the situation a bit); it's *mostly* the result of the dotcom bust -- which, incidentally, was a necessary correction; if the boom had gone on too much longer, the stock market continuing to do the sorts of crazy things it was doing in the nineties, we'd have ended up in another ten or fifteen years with a second great depression. As it is, we got off with a relatively mild depression, as things go. Anyway, about the labor surplus: the world of nursing goes through this every twenty years or so; the main reason is because it's an attractive field to certain types of people, and so whenever there are plenty of jobs available in the field, lots of people study to become a nurse. Then when they all graduate and go get jobs, there's a surplus. Some of the nurses end up getting jobs in other fields, then. This corrects itself after a few years, because the lower wages cause guidance counsellors and parents to steer people away from nursing toward other careers, and then when all those surplus nurses hit retirement age there's a shortage, and the cycle repeats. Any type of job that makes people think, "Gosh, I want to do *that* for a living" will have this sort of cycle (*unless* it's got such great appeal that in the middle of a labor surplus when it's virtually impossible to get work in the field, people still think, "Gosh, I want to do *that* with my life, and try to make a living at it; fields such as acting and professional sports have a perpetual labor surplus for this reason).
It is true that outsourcing is aggravating the current labor surplus in information technology. Back to that point:
> when they try to find another job there are more candidates than jobs > so salaries go down and they are lucky to get a job at ANY wage.
If they don't get a job in IT, there *are* other fields. The normal thing that happens when a particular line of work no longer pays is that you go and get a job in another line of work. These IT workers are not dustbowl farmers unqualified for any other job, and we do not have anything remotely close the sort of runaway unemployment that leads to people starving to death.
> That brings wages down across the board - not just in tech.
That's called a "recession" (or, if you will, a "depression", which is
Slashdot Mirror
> When you tell Bob you like his pink flannel shirt, are you lying?
> [...] People who don't lie at the right times are called "assholes".
The idea that you have a choice between lying and maliciously making Bob
feel like a loser who can't dress himself is a false dichotomy. It's hard
for geeks, I know, because I have a good deal of trouble with it myself, but
there's this thing called tact: the ability to tell the truth without stirring
up unnecessary trouble. If Bob's new visible-from-space pink-and-orange shirt
makes you want to pulk, telling him you think it's "simply wonderful" is a lie.
Telling him it makes you want to pulk is tactless and needlessly provocative.
Tactful is something along the lines of, "Actually, I rather like the blue
shirt you wore the other day." This is difficult to do on the spot, sometimes,
granted. Especially for people like me who are highly unlikely to have *any*
idea what the person wore yesterday, the day before, or ever. (Heck, I don't
remember what *I* wore yesterday.) Another possible mostly-tactful response
would be, "Oh, Bob, I'm not the one to ask about fashion stuff. I'm no good
at that sort of thing."
I once managed to tell a 40-year-old female coworker who had just had her hair
cut short and asked how we all liked it that I _didn't_ particularly like it,
without hurting her feelings. I told her that I had liked it better the
other way. As it turned out, it just happened that she wasn't really happy
with the cut herself, but with everyone saying how much they liked it she
wasn't going to admit that until someone else said otherwise. Maybe I just
got lucky? Maybe. Or maybe there's something to be said for tact.
> Language Diversity.
Language Diversity rules. However, a really good language ought to be designed
so that you can use diverse programming paradigms within the limits of that
language. Perl is taking some steps along these lines. Perl5 already has very
good support for procedural programming, basic functional programming, basic
contextual programming, and with a little work you can get it to do basic OO
programming also. Perl6 is revamping the OO stuff to be a first-class citizen,
as well as bolstering the contextual and functional stuff too. (There's even
talk of continuations and lazy evaluation.) There is also talk of adding
support for logical programming (a la prolog), but I don't know whether that's
really going to happen.
There's still work to do, of course. Perl6 is a long way from being ready.
But the list of languages that have influenced its design is *lengthy*.
Right now, there are things I can do in elisp or Inform easier than in Perl5.
The object model coming in Perl6 will shorten that list to just elisp, and
it will be possible to implement textbuffers using the Perl6 object model;
if someone (such as myself -- I'm seriously thinking about it) does so and
puts it on CPAN, then I won't need elisp either, except for customizing Emacs.
So now I'm learning Scheme, which has some *more* things Perl5 doesn't have,
such as continuations -- but word has it these things are going to be in
Perl6, so I figure I'll get a leg up on the concepts by understanding them
in Scheme now.
Hopefully, multiparadigmatic VHLLs such as Perl, Python, and so forth will
utterly take over, eventually, except for extreme low-level stuff like
bootloaders and device drivers. For that to happen, we'll probably need
optimizing compilers for these languages, or a really good, ubiquitous VM.
(Parrot hopes to be the latter. We'll see how that goes. The Java VM is
almost ubiquitous enough, but it's not good enough, and none of the VHLLs
target it AFAIK (presumably because it's designed especially for Java).)
> dude, if I had to look at a desktop like that the whole day, I would also
> get unusually sensitive eyes, as well as some serious other accessibility
> requirements, primarily in the mental area....
Yeah, none of my coworkers like it either. "Why don't you use some more
interesting colors?" "Like what", I ask. "Oh, I don't know, white?"
I seriously don't understand the obsession that the rest of the world has
with color settings that make you go snowblind in two minutes flat. I know,
lots and lots of people like it that way. Not me. I prefer *not* to have
to wear sunglasses to use my computer, thanks. Actually, that's the good
thing about my colors: I can look at them for twelve hours without getting
eyestrain. "Normal", black-on-white color schemes make me have to close my
eyes for a couple of minutes every little bit, and after a five hour shift
I need to lay down in a dark room with my eyes closed and sleep off a
headache. I have almost all of the computers at work (all the ones I have
to work with with any frequency) set so that the "light" background color
for windows is more like #CCCCCC instead of #FFFFFF, so that I don't go
blind every time I have to do anything with them. Still, after a few
minutes I need to get away from that screen, back to my nice calm tertiary
color scheme.
Of course, I also have a black trashbag taped over the window in my bedroom,
and I don't like to be outside in the daytime... so I guess my eyes are a
bit more sensitive to light than average. I can read by the light of a
single votive candle on the other side of the room without difficulty.
I also see much better than average in the dark. The only place I've
ever been where it was too dark for me to see effectively was in Mammoth
Cave when they turned out the lights to demonstrate actual factual darkness.
> Am I not as capable of having fun as I once was, or what?
Maybe your ideas about what is "fun" are changing. This in itself is not a
bad thing. When you were eight, you probably thought it was fun to run around
on a blacktop with eight-year-old children. At some point you may have thought
it was tremendous fun to read those lame, elementary-school joke books, such
as "101 Fun Food Jokes". Think that's fun now, do you?
The first time I ever played a 3D FPS (it was Wolfenstein 3D at the time), I
thought it was pretty cool. At this point, I've had a belly full of those
and don't care if I never see another one.
Here's one of mine, which demonstrates an unusual accessibility requirement (the soft tertiary colors -- my eyes are unusally sensitive to light; I CANNOT handle Evil Blinding Backgrounds or high contrast). It also demonstrates the left side panel full of launchers, drawers, and applets that I've grown to love. The only things on the bottom panel are the task list and the clock. If it matters, this is a Mandrake 9.2 system with Gnome (but I replaced Metacity with Sawfish (because I want features, darnit) and replaced Nautilus with nothing (because I do all my file management from the command line)). The top drawer (with the drawer icon) holds the foot menu and launchers for assorted utilities and configuration things. The next drawer down, the one with the gnome-terminal icon, holds launchers for gnome-terminal (with various terminal classes and commands -- e.g., one for MySQL, one that does ssh into the cgi server, one that does ssh into the router, and so on). The drawer below that holds launchers for browsers. Then you've got three launchers right on the panel because I use them a lot: OO, Gimp, Emacs. Below the blank space is the screenshot button, the run button, a drawer of audio stuff, a drawer of games, the show desktop button (which really I ought to remove; I never use it), the CPU, memory, and swap meters, and the log out button at the bottom, out of the way. (Does anyone else think the Gnome1 logout icon looked nicer, or is that just me?)
That Mozilla window has been open for some while; the first two tabs in particular have been open for a couple of weeks. This is typical.
One of the Emacs windows has eshell, which is running a telnet connection to the im2 multiplexer for the Perlmonks.org chatterbox. Another is Gnus. The third has open the Changes file for Net::Server::POP3, which is what I really ought to be working on instead of posting to slashdot.
Be sure to get a screenshot showing gdmflexiserver running with the Xnest option. That's a really cool feature. For bonus points, have a different desktop environment running inside the Xnest window than the one running outside it. Also try to get a shot from someone who uses ratpoison; there's no window manager more minimalist than that, especially when it comes to window decorations. Be certain to show off several interesting panel applets, especially if you can get one running in a tiny always-on-top panel. Get one showing something really cool being worked on in Gimp, too. And be sure to get an Enlightenment screenshot showing that weird dragbar thing about halfway up/down the screen. I don't personally like that, but it's innovative and different, and some people swear by it.
> > I tried to learn PHP, but I got really tired of reading about how
> > much "better" PHP is than Perl because it's Not CGI(TM).
>
> Care to point out where the PHP documentation states that? Or are you
> just judging the language by a vocal minority of its users?
Huh. It appears to be *gone*. It was there, honest. I googled for PHP,
went to the first result that wasn't a paid advert, and clicked on a link
that said something like "tutorial" or "documentation". This was a little
while ago, though (at least a year).
Still, the manual at http://www.php.net/manual/en/index.php seems to me
to be a revision of the same documentation I was reading. A lot of the
wording in it is very very familiar to me, so I'm almost sure it's the same
document (or the one I saw copied from this one, or vice versa, or something).
However, all that negative CGI-bashing is *gone*, as if someone has edited
the document ad interim and cleaned all that junk out.
So, um, ignore my ranting; this issue appears to have already been fixed,
and I'm just behind the times. There's nothing to see here; move along.
> Only and the biggest problem with Win-Live CD is that YOU CAN'T PATCH IT!
That's no big deal; you don't patch a Live CD anyway; there's no point. You
just get the latest version.
I would expect the *big* problems with a Windows Live CD to be in terms of
hardware support and the expectations of applications. With regard to the
former, Microsoft has for a LONG time now relied on the hardware manufacturers
to supply almost all of the drivers. It is almost impossible to build a
complete system entirely out of hardware that will work with Windows without
installing manufacturer drivers. Microsoft (or whoever was licensing Windows
to produce the Live CD) would have to license all the drivers from the vendors
of the hardware. No individual driver would be a problem (vendors would want
their product to work with the Windows Live CD), but there are a *lot* of them,
and tracking down agreements for all of them would be a significant pain. I
would expect such a project to take at least a year.
The other problem is worse. LOTS of applications won't run on Windows XP
unless you log in as a user with Administrator privileges. (This is *one*
of the reasons OEMs all ship with a passwordless Owner account and no
non-privileged user accounts.) There are assorted reasons why apps don't
work without Admin privs, but mostly it boils down to their having been
designed, a couple of versions ago, for Windows 98, where that stuff just
doesn't matter. Judging by the number of applications still in use today
that do various highly-deprecated things (use the DOS API, require to be
installed in C:\APPNAME, store the user's documents in the application's
directory under Progra~1, and assorted other schenanighans along the same
lines) it seems unlikely that the apps will all be capable of running in a
tightly controlled environment any time soon. Of course, I'm mostly not
talking here about general-purpose apps like word processors, but more in
terms of field-specific custom stuff, like library automation software,
hospital software, accounting software, and so on. The general-purpose apps
are mostly somewhat better behaved, and so for scenerios where nothing very
special is needed the bootable Windows Live CD might be practical within a
few years. I won't be holding my breath though.
Heck, I'd be happy just to have a bootable Windows CD that's usable as a
rescue system. Something along the lines of Knoppix but with regedit and
other Windows-specific things. If it would run on all the hardware Knoppix
runs on, I'd be ecstatic. If I could afford the thing, that is. Windows
really ought to ship with such a thing in the box. Well, the Pro edition
should, anyway.
Are they rewriting the docs to actually explain the features of the language
and how to use them? I tried to learn PHP, but I got really tired of reading
about how much "better" PHP is than Perl because it's Not CGI(TM). Come on,
stop *saying* it's better and *show* me it's any good. What features does
the language have? How would I go about using them? If PHP is so good, the
docs ought to be able to convince me of that without endlessly repeating it.
I also got tired of seeing what ought to have been one-liners written in
fifteen or twenty lines of PHP. Is the language really that needlessly
verbose, or are those just bad examples?
In summary, the documentation is so bad, I can't even make a decent evaluation
of whether the language is any good. The *first* thing the PHP crowd needs to
fix is the documentation. It ought to be rewritten from scratch.
> I've seen somebody tring to do cross-tab reports in a single step in SQL
> (I think it was based on a query in Joe Celko's SQL for Smarties book).
> It worked fine with a few hundred to a couple of thousand rows of data
> (less than 5 secs), but by the time it had grown to only 10,000 rows, the
> query would take more than an hour. This is the same machine that runs some
> other simpler queries against a 250 million row table in under 15 secs. The
> point being that a simpler version of the query would run in a few seconds,
> and then Excel could do the cross-tabulation with copy-and-pasted data for
> total of 5 minutes extra effort.
Excel isn't the only (or even necessarily the best) tool for this sort of
thing. I've often found myself doing an SQL query via DBI, then filtering
the list of record hashrefs with Perl's "grep" list transform operator.
But your point generally is a good one: sometimes it's faster to use a
simple query to fetch a bunch of data and then filter it, rather than
using a complex query to fetch exactly the right data. This also applies
more broadly than database stuff. Just a couple of weeks ago I was writing
a simple script that automates the process of doing something (I forget what)
on the web, using WWW::Mechanize, and it needed to extract a certain element
from the page. Rather than trying to extract just the one needed element,
it was easier to use HTML::Tree and look_down to extract all the elements
of the right type (td IIRC) and then grep the list for the one in question.
> Do you do your own fillings too, instead of going to the dentist?
> You hire me (a profrssional database programmer) to write a database
I don't do my own fillings, but I do brush my own teeth. We're talking about
*simple* databases here. One table. Five or six fields. Fifty records.
The kind of stuff people do in Access, or even in the database portion of
Microsoft Works (as of version 4, anyway; not sure if the current version
of Works still has that). Hiring a DBA for this stuff would be like paying
a CPA to fill out my 1040EZ. (Yes, there *are* people who do that...)
More than 99% of all the world's databases are tiny little one-table things
like this. We've got eight or nine of them where I work, and about ten
full-time staff, plus several students who work part-time, a maintenance
guy and a cleaning lady, for a grand total of maybe twice as many employees
as one-table databases. None of these databases have more than nine or ten
fields, and none of them have more than a couple of hundred records. This
seems to be typical; when I was in college, the professor I worked for had
half a dozen databases very similar to this. At the time he was in the
process of switching them from MS Works to Access. He was also in the
process of migrating documents from WordPerfect 5.1 to Word 6. (Stop
looking at me like I'm some kind of geezer. It wasn't *that* long ago.)
That said, I do this stuff in MySQL and set up a Perl CGI frontend. I think
I'm a bit more of a poweruser than the average Access user though. It'll be
good when OpenOffice has a database frontend. (This is in the works, but
it's not ready for end users yet.)
There are a couple of problems with doing these one-table databases in a
spreadsheet, but the most obvious is that the user can't just click on a
field title to sort by that field. Also, there are no advantages to the
spreadsheet approach. I've used that approach in the past, but I don't
favor it. The one-table database is better for this. Spreadsheets are
for keeping your checkbook and stuff like that, where you have a lot of
calculated cells, and the stuff on one line is derived partly from the
previous line. If the lines have no particular order, or might need to
be sorted in one of several orders (by different columns), a database is
the way to go, even if it's a tiny little one-table database with columns
for "name", "address", "phone", "year joined", "paid thru", and "notes".
> MS access took me far longer as it was not entirely conforming to
> open standards (i.e. SQL)
Nothing conforms to the open SQL standard. Get the SQL in a Nutshell book,
and start comparing SQL99 to the various implementations. MySQL is nowhere
near conforming. PostgreSQL is a little better, but far from perfect. MS
SQL Server and Oracle both deviate too.
I'm all for standards, but the SQL standard is still waiting for even one
conforming implementation, as far as I know.
That said, I also spent more time trying to figure out Access than I spent
learning the basics of MySQL. However, I had a book (the abovementioned
one) for learning MySQL, and when I was messing with Access I had only the
help files. Also, that was a while ago, a version of Access that would now
be considered horribly obsolete. (It ran on Windows 3.1...) For all I know
the current version of Access may be better. (Or it may not; I wouldn't know,
as I've not seen it. The regular version of Office doesn't even include it
anymore.)
Also, I cut my teeth on PC-DOS 3.3, so I'm comfortable with command-line
interfaces. People whose first computer ran Windows 95 might have a harder
time learning to use MySQL (though there is that mysqlcc thingy; I've barely
experimented with that at all, so I won't comment further).
> Access Database support...
You can access Access databases from Perl, using the DBI, so I don't imagine
there's anything in particular stopping OpenOffice from supporting it too,
except that the OO.o database frontend thingy isn't really ready for end
users yet. (IBM could put a couple of programmers on the project and fix
that in a few months, if they wanted to take that route.)
I think it's more about IBM not wanting to switch people over to OpenOffice
for training reasons. OpenOffice is great, but it is different from MS Office.
At work we have two computers with MS Office, and every time someone asks me
a question about it I hunt around in Help for the answer, get frustrated, open
the document in OpenOffice, and solve their problem there -- because OpenOffice
is what I have at home, what I have on my desktop at work, and what I know --
and Microsoft Office is different. If you were going the other direction, you
would probably have the same issues. So that's why IBM wants MS Office -- it's
what their customers are currently using, and they don't want to retrain them.
> I would love to use a C/C++/Java-like language that utilizes pure objects
If it had a good object system, wouldn't that make it totally unlike C, C++,
or Java? At least, semantically it would. I suppose the syntax could be
C-like. Inform for example has C-like syntax, but the object system is so
much more advanced than the one used by C++ that there is no comparison.
(Inform, however, is not a general-purpose language. It doesn't have the
I/O capabilities to be general-purpose. This is mostly due to the virtual
machine it's designed to compile to, which for portability reasons doesn't
support such things as a filesystem per se. But it's a great language for
its intended problem space.)
> FORTRAN is highly counter-intuitive, but it's a damn fast number crunching
> language (rivaled only by C, if I remember my benchmarks correctly).
FORTRAN is more than merely *rivaled* by C; when it comes to being highly
counter-intuitive, FORTRAN is utterly *outclassed* by C.
Oh, you meant rivaled in terms of the speed of number cruching? Then, yeah,
as long as the numbers in question are small enough to be represented by C
data types. Otherwise, it's best to stick with FORTRAN for that.
(Please note that I'm not advocating FORTRAN for things *other* than number
crunching. It's utterly worthless for text handling, for example. For that
you use Perl.)
> I'm not suggesting that we do away with basic arithmetic or variable
> assignment. You can't do that and still have a programming language.
Well, you *can*... unlambda for example doesn't have *anything* like
variable assignment, nor does it directly include any arithmetic primitives
(though it is possible to do arithmetic indirectly).
> The very idea [...] is just plain silly.
I think unlambda is more scary than silly.
> You just can't 'fix' bad programmers with better languages.
No, of course not. You can remove certain very common and problematic
classes of bugs, though, such as buffer overflows, segfaults, and memory
leaks. But there will always be application-specific logic bugs, and there
are classes of common bugs (e.g., infinite loops) that cannot be easily
solved at the language level (except by crippling the language, which is
unuseful).
> Perl's OO model isn't.
Agreed. I love Perl to death, but the OO sucks rocks. (But then, I don't
like the OO in C++ any better. I guess Inform's wonderful object system
has be spoiled.) This is getting fixed in Perl6, but of course that's all
in the future at this point. (We haven't even got the Apocalypse article
on objects yet, though we've got quite a lot of information about them
already from the previous articles.)
The thing I like about Perl the most is the multiparadigmatic approach. (Well,
that and the CPAN. CPAN rules. It's like sourceforge and portage all rolled
into one, plus better documentation and better searching facilities.) What
do I mean by "multiparadigmatic approach"? I mean, I can use freely interleave
functional, object, imperative, and contextual styles, using whatever best fits
the problem I'm solving. If it suits my purposes, I can have a global array
of hashrefs, and each hash can hold several closures that share between them
(within that hash, but separate from the others) an object (say, a DBI handle).
Or, if it suits my purposes better, I can have a class of objects that each
retain as one of their properties a closure that holds a private array of
helper objects -- and that's just using the major traditional paradigms
(object, functional, and imperative). Perl also has the contextual paradigm,
which once you get the hang of it is incredibly useful.
And yeah, when I read this slashdot blurb...
> First, making software more 'intuitive' for developers will reduce bugs.
> Second, software should more closely simulate the real world, so we should
> be expanding the pure object-oriented paradigm to allow for a richer set
> of basic abstractions -- like processes and conditions.
I immediately thought, "Oh, in other words we should use Perl, or something
a heck of a lot like Perl."
> I prefer C/C++ because things are pretty explicit, ie. you need to define
:-)
> your variables explicitly before you use them
You can fix this in Perl. Just put the following line at the top of each file:
use strict;
> However, with Perl, there are so many things that if they aren't present,
> they are assumed. It is very "hacky" and makes it very hard to read.
Only when you're very new to the language. Once you've learned it, the
terseness makes it possible to see whole functions -- indeed, whole entire
algorithms -- on the screen at one time in a clear, easy-to-follow layout.
(Pay no attention to my signature; that's that way on purpose, and if you
think C is immune to obfuscation, google for IOCCC sometime.)
Having all that superfluous redundant stuff written out just turns simple
functions that ought to be ten lines (half of that comments) into multi-page
monstrosities that require several minutes to read and understand. Bleah.
If you don't like Perl, try Python. It's more strict about a lot of stuff,
so you might like it better, if you're into that sort of thing. However, it
shares with Perl certain very critical features that every language ought to
have, such as built-in memory management. (No more buffer overflows EVER
Personally, I tried Python, didn't care for it, and went back to Perl.
Reiser would be harder to do, I think, than (say) ext2/ext3. The Reiser fs
... it's a great fs for a
is designed to be a good filesystem, not to be easy to implement. (In that
respect, it's somewhat like NTFS I think and nothing at all like FAT.)
Actually, in terms of a filesystem being easy to implement, nothing[1] tops
plain old ordinary FAT. Even FAT with LFNs and such (vfat, that's sometimes
called) isn't too bad. Nice and simple. Only problem is, there are too many
things it doesn't support: journaling, file ownership, multiple sets of
permissions for different classes of users,
multiboot user to use for storing stuff you want to be able to access from
all your different OSes -- just have one partition that's dedicated to
documents and other data that you want to be able to get to from any OS.
However, FAT doesn't make such a good OS for installing an OS and applications
on, for the reasons listed.
Anyway, writing lowlevel Windows software to let you mount ext2/3 filesystems
would be an interesting and useful (albeit probably not easy) project, but it
wouldn't help one iota in terms of letting you use Linux as a rescue system
for doing repairs to Windows, nor would it let you access the data on a
stock-out-of-the-box Windows system, so it's no substitute for real NTFS
support. captive-NTFS will do for now (especially once the Knoppix version
with it comes out), but it would be nice to have real native NTFS support.
[1] Nothing that's usable as a filesystem for a general-purpose OS, I mean.
Obviously you could have a super-simple filesystem that just treats the
whole disk as one big hogfile (DHF), for example, which would be easier
than a bubble sort to implement, but performance would be like sucking
gravel through a coffee stir, and there wouldn't be any robustness.
(scandisk or fsck? forget it; if you need to check the filesystem, you
probably need to reformat the part of the drive from the point of
corruption upward.) Also, no directories, and no long filenames...
> You, my friend, win for best line I have ever read on slashdot ...
> > IANAL, but from what I've read on slashdot...
> This is good stuff
The wording was deliberately worded in such a way as to avoid giving anyone
the impression that I was remotely certain about what I was saying. It was
an idea that was running through my head, no more.
> Maybe they are taking some ideas from SCO on how to profit from the OSS
> community.
SCO is profitting from investors (mainly two large ones), not from the OSS
community. The OSS community is only involved as a way of generating some
publicity. (It's a remarkably complex way to generate publicity, but that's
what they're doing (quite successfully, I might add). The process is really
too involved to classify as a "stunt", though, as that would imply a
terminating sequence of simple events; SCO's publicity engine seems to be
more of an ongoing thing.)
Microsoft doesn't *need* the OSS community to generate publicity; they can
get media attention as easily as the President of the United States. And
over the medium or long term they seem to be much better than SCO at making
profit. So no, I don't think Microsoft is planning to pull a SCO for the
purpose of generating revenue.
If they *were* planning a lawsuit (which seems unlikely; not that I'd put
it past them, but the leak is more easily explained elsewise; various things
seem to leak out of MS regularly, not all of which Microsoft wants released,
I'm pretty sure; there's no reason to believe this is different) it would be
for the purpose of squelching competition, not generating revenue directly.
> it'd sure be nice to have a way to get rid of [Outlook Express]
An easier way, I mean. What one has to go through to do it the way I know
how is rediculous. Every new WinXP system we get I have to devote at least
an hour to hunting down and removing all the MSOE components; it's a pain, but
I'm not willing to support a network that has OE on it; that would be worse.
> people should realise that the NT kernel is actually an extremely sensibly
... but that's not security maintenance).
> structured and well written system, it's just most of the peripheral junk
> like IE that's bundled on top that leaves something to be desired.
I don't know exactly how sensibly-written the NT kernel is (other than that
it's obviously *way* better than the Win9x kernel; that much is clear). I
do know that certain apps bundled with it (most notably Outlook Express) are
much worse than the mere waste that you mention[1] but more akin to poison, as
they *actively* compromise security. (OE (or something) also actively takes
measures to prevent you from removing it and/or restore it if you do, which
as far as I'm concerned qualifies it as a virus.) So the kernel is certainly
not the major problem with current NT systems. As near as I can tell, the
kernel's not half bad, but some of the other components of the system are
much worse than half bad. If you want to call Outlook Express "peripheral
junk", sure, then I can agree with what you say, but it'd sure be nice to
have a way to get rid of the peripheral junk. (And don't say "just don't
use it"; I have to deploy to users who don't know the difference between
My Computer and their ISP; they're sure not going to know whether they're
using Outlook Express or not; I want it *removed* from the system, GONE.)
> I've been using my machine for 4 years with Win2k, and never got a virus
> and never got exploited.
Yeah, I've been maintaining a network since 2000 April (not quite 4 years
yet) that's currently got nine (about to be ten) Windows systems on it of
one flavour or another (plus several macs, a couple of Mandrake systems,
and one OpenVMS), and the last time we had anything that resembled a virus
running on our systems was Bonzi Buddy which was already there when I was
hired, and I cleaned it off sometime in 2000. (I say "running" because we
did have a situation where a virus file got deposited on an exposed network
share, but it never got executed on our systems and I got rid of it and
moved the network share behind a NAT gateway (specifically, a headless
Mandrake box doing IP Masquerade).) But I've accomplished this by making
darn sure there are no MSIE shortcuts on the desktop or start menu, making
sure MSOE (and in some cases Outlook -- we have a couple of systems with
Office) is non-functional (which is much harder on XP than on Win98, I
might note), having no working removable-media drives on certain systems
(ones that are accessible to random persons and connected to the network),
and other measures that really ought not to be necessary. Sure, it's
*possible* to secure Windows systems, but it's entirely too much work.
I've put almost no time into keeping the Mac systems secure and for the
Linux systems I only had to upgrade server-type apps a handful of times;
if they hadn't been running any server stuff (the Windows systems aren't),
then they wouldn't have needed any maintenance at all (unless there were
new features available in the new versions that I wanted, like Emacs 21,
browser upgrades,
My hatred is particularly strong for Outlook Express. I want it removed
from the universe, sooner rather than later. (Today would be good.
Yesterday would be better. Five years ago would be wonderful.) I don't
even want people to remember it. *I* certainly won't want to remember it.
[1] You used a less-kind word for it. You know the stuff I mean.
If (and this is the sort of "if" that places us well more than a mere one leap
away from reality) the WINE team had full legal access to the Windows source
code granted them by Microsoft, the miracle version of WINE would definitely
not come out "within a few weeks". The job of ingesting all that info and
getting a feel for the organisational peculiarities of a codebase that large
would impose a multi-month overhead before you could really even start to do
meaningful work.
Actually, that's exactly what I was going to suggest, though not by copying. ...". (I don't know beans
I was going to say the first thing anyone competent in C/C++ who gets their
hands on the code ought to do (providing they don't need to take a hands-off
approach due to, say, the need to be able to legally write competing OS code)
would be to post English descriptions anonymously to usenet, describing the
way NTFS works, especially the parts that are not currently well-understood.
No source code snippets, just stuff like "it appears that such-and-such
information about each file is stored and updated whenever it changes in three
places: at offset blah in the file header info, and
about NTFS, so any fs jargon that leaked into that sentence may not be accurate.
But you get the idea of the kind of thing I mean.)
Then somebody else could take that information and implement a compatible
filesystem in a clean-room fashion.
IANAL, but from what I've read on slashdot, there's apparently at least a
vague possibility the resulting code might be legal. Though, one should
consult legal counsel before spending significant time on such a project.
> > When that happens, which will usually be sooner rather than later, the
> > US ecconomy regains the twenty billion in GNP that it lost due to the
> > oursourcing.
>
> Correct me if I'm wrong (which I am sure you will do), but isn't that
> EXACTLY what I said that you disagreed with, saying economics doesn't
> work that way?
I then went on to explain why it doesn't work that way, but apparently my
explanation wasn't clear enough for you.
> Let's bring down your argument to a more human level
In other words, let's make an emotional plea instead of being rational, so we
can get people excited about the starving children of the farmers, so they'll
forget about the ecconomics of the situation. Try to remember that the
depression was not caused by outsourcing jobs to the third world but by a
sudden correction in the stock market, which had become greatly inflated in
the previous years, due to not having enough smaller downward corrections.
> Tech workers today are out of a job because the companies found a cheaper
> labor force, but when they try to find another job there are more candidates
> than jobs so salaries go down and they are lucky to get a job at ANY wage.
You exaggerate. Greatly. We're not starving. Most of us aren't even
completely without work. In fact, it's still a fairly decent field to be in,
on the whole. Tech workers have just experienced for the first time what
workers in other industries have known about for centuries: a labor surplus.
This is not mostly the result of outsourcing (though that can aggravate the
situation a bit); it's *mostly* the result of the dotcom bust -- which,
incidentally, was a necessary correction; if the boom had gone on too much
longer, the stock market continuing to do the sorts of crazy things it was
doing in the nineties, we'd have ended up in another ten or fifteen years with
a second great depression. As it is, we got off with a relatively mild
depression, as things go. Anyway, about the labor surplus: the world of
nursing goes through this every twenty years or so; the main reason is because
it's an attractive field to certain types of people, and so whenever there are
plenty of jobs available in the field, lots of people study to become a nurse.
Then when they all graduate and go get jobs, there's a surplus. Some of the
nurses end up getting jobs in other fields, then. This corrects itself after
a few years, because the lower wages cause guidance counsellors and parents to
steer people away from nursing toward other careers, and then when all those
surplus nurses hit retirement age there's a shortage, and the cycle repeats.
Any type of job that makes people think, "Gosh, I want to do *that* for a
living" will have this sort of cycle (*unless* it's got such great appeal
that in the middle of a labor surplus when it's virtually impossible to get
work in the field, people still think, "Gosh, I want to do *that* with my
life, and try to make a living at it; fields such as acting and professional
sports have a perpetual labor surplus for this reason).
It is true that outsourcing is aggravating the current labor surplus in
information technology. Back to that point:
> when they try to find another job there are more candidates than jobs
> so salaries go down and they are lucky to get a job at ANY wage.
If they don't get a job in IT, there *are* other fields. The normal thing
that happens when a particular line of work no longer pays is that you go
and get a job in another line of work. These IT workers are not dustbowl
farmers unqualified for any other job, and we do not have anything remotely
close the sort of runaway unemployment that leads to people starving to death.
> That brings wages down across the board - not just in tech.
That's called a "recession" (or, if you will, a "depression", which is