Re:Here's what I'm sending to my State Senetor
on
UCITA is passed
·
· Score: 1
You've got some spelling errors in there, but that's not necessarily bad -- it may make your message seem more like "the voice of the people". Or something.
Here's mine:
I'm writing to you to express my strong opposition to the proposed Uniform Computer Information Transactions Act (UCITA), which was recently passed by the National Conference of Commissioners on Uniform State Laws. I hope that you will speak and vote against UCITA if/when it is introduced.
Rather than attempt to compile a comprehensive list of all the problems with UCITA (which would be terribly long and boring), I will discuss only the two most serious problems that I see.
The freedom to reverse engineer software must not be denied.
Reverse engineering is simply a fancy way of saying "taking something apart to see how it works". No other product has such draconian laws governing what may be done with it once it has been purchased. As a consumer, I'm free to make such small repairs as I am capable of to other products that I own, or to choose a more qualified technician to make repairs for me -- I don't have to take it back to the original dealer.
But UCITA would put computer software in a special class, with restrictions governing its use in ways that don't affect other products.
In the long run, UCITA may lead to an economic disaster.
By disallowing reverse engineering, UCITA gives total control over software to the people who wrote it. The software cannot undergo independent testing to determine whether it contains any flaws, because all but the most superficial tests would require some knowledge of how the software works (which could be obtained only by reverse engineering).
Without testing, "bugs" in software may go unnoticed for long periods of time, becoming a problem only after the software has been in use just long enough to become indispensable. But because the bugs won't be noticed at first, the software companies will find they have a captive market. There will be no incentive to improve their products or their service. And there will be no competition -- developing a competing product would require reverse engineering the flawed one.
In the short term, this may lead to increased revenues for software companies. But in the long run, the software industry will be dominated by software which is overpriced and which does not work very well. People and companies trying to use this software will end up paying more and getting less in return. Products which rely on the software will fail more often, as the underlying software fails. This leads to a downward spiral which can only end in disaster.
For these reasons, and many others too numerous to mention in this letter, I urge you to OPPOSE any proposed UCITA legislation.
Yes, Bruce's Technocrat.net site is a wonderful thing. For those who missed the earlier story, Technocrat.net is devoted to "technology policy" -- laws which affect technology. It may take a while for the site to become popular, and may go through some growing pains, but if it can actually serve to bridge the gap between computer techies and non-computer techies, it may help educate everyone. (I've learned quite a bit from it already -- I'm quite familiar with the computer-related stories, but I haven't followed the space exploration stories as much, and I didn't know anything about amateur radio.)
I've already submitted a UCITA story to that site. I imagine a lot of other people have, too. I haven't seen one posted yet, but I can't possibly imagine this story not showing up there.
AIX's implementation of LVM is one of the best IMO. Granted, you can't shrink lvs or fs's, but you can increase their size while in full multiuser mode.
Indeed. The Logical Volume Manager is AIX's best feature. It's really good.
AIX can also perform many kernel reconfig tasks without rebooting, as it has a dynamic kernel. The ODM is necessary to support this.
I've found that Linux's kernel has as many, if not more, dynamic features. Installing a newer device driver under AIX does a "bosboot" (which rebuilds the kernel and the boot area) and requires a reboot to take effect. Under Linux, if your kernel is modular, you can recompile a device driver module and then unload and reinsert it without rebooting. Solaris has a similar feature. Also, Linux has a/proc file system (assuming your kernel was compiled with it -- it's the default) which permits on-the-fly parameter reading and writing. AIX does a lot of nifty magic for you, but it's all behind the scenes -- you can't get status information from the kernel through any normal, documented procedures as far as I know.
I don't understand why you think the ODM is necessary for the kernel to do things dynamically. Linux and Solaris have no registry (which is what ODM is -- a binary database of system parameters) and they're just as dynamic as AIX.
Actually, can anyone confirm the rumour I've heard that 3.2.5 has some Y2K issues?
Out of the box, yes. I don't know whether there are a full set of Y2K patches for it -- but if so, the list will be pretty damned huge. Here's the y2k_fixcheck output for our last AIX 3.2 system. (We just replaced this box with a larger box running 4.3.2 this weekend, so this 3.2 box is no longer in production. We're keeping it around for a little while though, mostly for reference, as the last production switchover problems are being mopped up.)
******** AIX Year 2000 Update Search Tool ****** (v2.2 April 1999)
Starting check. Getting version information. AIX Version 3 Release 2 Searching update database.......... PTF U444180 for bos.obj not yet applied. . PTF U444250 for bos.obj not yet applied. . PTF U447667 for bos.obj not yet applied. . PTF U447694 for bos.obj not yet applied. . PTF U447704 for bos.obj not yet applied. . PTF U450430 for bos.obj not yet applied. . PTF U450434 for bos.obj not yet applied. . PTF U450435 for bos.obj not yet applied. . PTF U450441 for bos.obj not yet applied. . PTF U450472 for bos.obj not yet applied. . PTF U457945 for bos.obj not yet applied. . PTF U457979 for bos.obj not yet applied. . PTF U458039 for bos.obj not yet applied. . PTF U458063 for bos.obj not yet applied. . PTF U447712 for bosadt.bosadt.obj not yet applied. . PTF U458000 for bosadt.prof.obj not yet applied. . PTF U450447 for bosext1.csh.obj not yet applied. . PTF U458047 for bosext1.mh.obj not yet applied. . PTF U445954 for bosnet.snmpd.obj not yet applied. . PTF U447709 for bosnet.tcpip.obj not yet applied. . PTF U450464 for bosnet.tcpip.obj not yet applied. . PTF U447683 for bsmEn_US.msg not yet applied. ... PTF U457956 for bosext2.acct.obj not yet applied.
*********** RESULTS OF UPDATE SEARCH ********** This tool examines the update levels of all installed AIX filesets for a level the same as or newer than any known Year 2000 update.
NOT AT LATEST APAR PACKAGE LEVEL
This installation contains filesets which require one or more of the Year 2000 APAR update packages for this release. IBM recommends that you obtain and read the AIX Year 2000 Workbook from your IBM representative or from the World Wide Web at
http://www.software.ibm.com/year2000/papers/aixy2k .html for information on the latest updates for your release.
You may then choose which updates to order and apply for this installation.
IBM recommends that you regularly check its AIX Year 2000 Workbook for status and information at http://www.software.ibm.com/year2000/papers/aixy2k .html. and the IBM Year 2000 information center for updated status at http://www.ibm.com/IBM/year2000/.
Re:Nice tactic to get Linux into enterprise market
on
Yellow Dog for RS/6000
·
· Score: 1
486's was (and is) run by single individuals and maybe small companies - and not heavy industries.
This is demonstrably false. I've administered 486-based Unix systems at major corporations in the past. At one site, they had a Sequent with 12 486DX2-50 processors in it. Yes, twelve. At another site, they had a dual-processor 486 NCR system (but I don't know the clock speed).
These were LARGE manufacturing/distrubtion companies. If you live in the USA, I guarantee you've heard of both of them; in one case, their influence is global. But I can't name them due to privacy considerations, contractual issues, professional courtesy, etc.
Of course, I also realize you're only talking about the server side (even though you didn't explicitly say so). If you count desktop, then I can pretty much guarantee that 95% or more of ALL corporations who have been in business for the last 5 years have, or had, some 80486 processors in house. Most of them probably still have them in service in desktop systems. Where I'm currently working, there are a whole truckload of IBM PS/2 486SX systems still in service. They've got the "Y2K OK" stickers with the black magic marker "X" over top of them to indicate that they're on death row -- but they're still in use! (And a worse piece of desktop equipment you've not seen in many a year, I promise you.... But that's what you get when you're a contractor -- the leftover trash.)
to keep underage children from seeing things that they probably aren't developed enough to see
A 16-year-old isn't "developed enough" to see sex? Many (perhaps most) 16-year-olds have already had sex. The rest have masturbated, most likely with considerable frequency.
One of the biggest problems I see with American media labeling is the implicit connection between sex and violence. You hear the phrase all the time -- "sex and violence", as in "We must protect children from all this sex and violence." But these two concepts have nothing in common apart from their tendency to be lumped together by clueless but well-intentioned moralists.
So how can we change this? What will it take to turn America from a paternalistic morass of enforced morality and uniformity into a viable, healthy land of choice, diversity and self-enlightenment?
We have several RS/6000 systems where I currently work. CA Unicenter was loaded on most of them... and for the most part hasn't been a problem. But on one particular machine, we were getting spontaneous "lock ups" (system could not fork() -- ping worked, but telnet would connect and then drop; console login was almost possible but you couldn't get as far as a shell prompt before it crapped out). These "lock ups" would happen after about a week of uptime, with no warning symptoms. We installed an rrdtool-based monitoring system (simple stuff -- load average, active virtual memory pages, etc.) -- there was no sign of danger before the "lock ups" at all.
We sent a crash dump to IBM for analysis. They told us the kernel heap had been corrupted.
We uninstalled CA Unicenter (which for reasons unknown to me loads itself into kernel space like a device driver). The system has been running continously for a good while now:
it allows you to use the software on any machine you own or lease.
Not good enough! I'm a consultant, and so the vast majority of the Unix work I do is for clients. The clients pay for this service. Thus, if I were to install the MagniComp version of rdist, I'd have to have a commercial-use license of some sort.
So, like, I figured I should read this license to figure out what's up. I looked around a bit and eventually found it.
The very first thing I noticed is that it's much, much more difficult for a layman to read and understand than the GNU GPL is. Now, everyone reading Slashdot knows how much controversy, confusion and debate the GPL has spawned -- imagine how much worse it would be if the GPL had been written in this incomprehensible style. The SCSL has no preamble which explains the intent of the license; and in order to make any sense of the text of the license, one must continually refer to the license's Glossary to figure out what is meant by all of the Capitalized Words. The SCSL is actually three or more separate licenses all concatenated together, and you have to read a meta-license to determine which of the sublicene(s) apply to you.
So, while I didn't bother reading all of the license, I got the following out of it:
The software is only free (in the Debian Free Software Guidelines sense) for Research Use. You can't use the software freely if you actually have a job. (The Internal Deployment Use sub-license isn't free, either.)
For any other use (including commercial use), there are unacceptable limitations. You can't distribute modifications, and you can't disassemble or reverse engineer executables.
The last thing I noticed, after I quit reading the license in disgust, was that there was a "session ID" appended to the URL. It seems that Sun wanted to track me as I browsed their site. Naughty Sun! (The actual URL that I got for the license when I finally got to it was http://www.sun.com/jini/licensing/scsl_jcp_v.1.6c_ web.html;$sessionid$E5HGUBAAAV2LDAMU VFZE3NQ -- but I snipped the "session ID" garbage from the end before adding the license link in the first paragraph.
Does Sun really think that programmers are so bone-headed that we won't see right through all of their little tricks? We (or our predecessors) are the people who built the Internet! We aren't stupid, and we notice details. Your lawyers can't bury us with avalanches of mumbo-jumbo, because we programmers will eventually pick our way through the maze and find the rotten trash you dropped at the exit.
By playing these petty little power games with us, Sun only continues to alienate us. This is why Java has met with such a cold reception among the technologically savvy user and programmer community -- Sun doesn't want to play by the rules.
Well, just remember that the ultimate power is ours, not theirs. We have the power to disregard Sun's offerings until they come up with a way to work with us instead of against us. Sun isn't offering anything we need -- they're trying to grow a market. We've already got the tools and the talent to go our own direction, without Sun's poisoned candy. So while Sun keeps shooting itself in the foot and feeding fluff to the "HTML coders", we can go on with our lives.
Too-often refresh. Every page I load is loaded dynamically. I can't think of a reason this would be HTML related, yet it doesn't happen at any other site.
It's not, strictly speaking, as HTML issue. It's an HTTP issue.
When a CGI program emits a page, it emits both HTTP headers (the most important of which is the Content-Type:) and the actual content (typically HTML, or Content-Type: text/html). There are several HTTP headers that can be used to control the caching behavior of browsers and proxies -- Expires: is probably the most powerful, but Last-Modified: is often easier to use correctly (depending on the content).
If you're in Netscape, check out the various details under View | Page Info. It's rather informative about the aging information.
When in doubt, if you're serious about your CGI development, you can telnet to the web server and issue HEAD commands manually to get the HTTP headers for your pages. Unfortunately, it's not at all easy to get the precise behavior of cookie-enabled sites (like Slashdot) doing this, since you'd have to manually encode and ship your cookie too....
Slashdot seems not to use any of the aging headers when logging on to the main page as a cookieless coward:
Tcl is a highly successful open source porduct which is now making money for its authors through the company they set up, Scriptics.
"Successful" by whose definition? If "successful" means "profitable", then yes, I suppose it was successful. But some of us do not measure success by the amount of money brought in. As a language, Tcl leaves many things to be desired (from what little I've seen of it), so by my own personal standard it is not a success.
The real driving force behind the GPL flame wars (like this one) is a conflict between philosophies. On one side, we have people who cannot understand motivations other than profits. On the other, we have people who are primarily motivated by things other than profits; but these people often fail to understand that there are people for whom money is more important than anything else.
In the middle, there are all the rest of us who try our best to explain things to both sides.:-(
Fixing Quake (was Re:what's the fscking deal?)
on
BO2K cracked
·
· Score: 1
couldn't be bothered writing 'su' and then a lengthy password every time he wants to play Quake
You'll probably want to do the same for the "hipnotic" and "rogue" directories, and make similar wrappers for the other quake binaries. Shame on id for not writing a better installation script.
(Sorry about the first one. I honestly thought the Preview button was on the left, not the right, and clicked Submit too fast.):(
Fixing Quake (was Re:what's the fscking deal?)
on
BO2K cracked
·
· Score: 1
couldn't be bothered writing 'su' and then a lengthy password every time he wants to play Quake
You'll probably want to do the same for the "hipnotic" and "rogue" directories, and make similar wrappers for the other quake binaries. Shame on id for not writing a better installation script.
couldn't you just comment that some portions of the code are LGPLed and the rest is GPLed[?]
No, you cannot. Section 1 of the GPL says this:
If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it.
When you combine GPL'd code with any other code to form a single work, the resulting work must be distributed under the terms of the GPL if it is distributed at all. (You may use the work yourself without ever revealing the source code, but you can't share or sell your work without sharing the source code.)
The CTP graphics are 16 bits. If your X server is running in 24-bit or 32-bit mode, then the graphics are converted on the fly, and the game will be much, much slower than if your X server is running in 16-bit mode. Try restarting X in 16-bit mode.
My serial port trackball doesn't work well with CivCTP for Linux. It works fine with all other X software I've used, but with CivCTP it jitters and shakes.
I haven't seen precisely that problem, but I can point out two possibly related issues:
The game is a CPU hog. It busy-loops, consuming all available CPU cycles. (I assume this is a legacy of the Windoze code, and I hope that as Loki gets more experience with Windoze-to-Linux porting this sort of thing will become less common.)
If your X server is running in 24-bit or 32-bit mode, the 16-bit CTP graphics are being converted on the fly. This slows everything way down, and I noticed extremely poor mouse pointer responsiveness (on a K6-2 @ 333 MHz!). Running X in 16-bit color instead of 32-bit color led to a dramatic response time improvement.
Problem #4: None of the symbolic links placed all over my filesystem worked.
This is a known problem. The symbolic links that are created by the installation script point to the wrong location. You can manually fix them to correct the problem. But I can understand how this could be confusing for Linux newbies.
Problem #7: This is the big one. After many hours of gameplay, the game burps. Segmentation fault. This has happened to me three times in a row. Seems to happen after many hours of play, but I haven't been watching memory or anything to know if there is a leak.
The game definitely leaks memory. You'll probably want to save and restart your game every few hours (depending on how quickly you play and how much RAM you've got -- your 64 MB is the same as mine, so you'll probably notice some thrashing after several hours of game play).
The upcoming patch is supposed to address some of the crashes that people have seen. (I haven't seen any crashes yet except for the alien life form ending.)
There is actually an autosave feature in CTP, though it's undocumented and unsupported in 1.0 and requires manual intervention both to turn it on and to get at the autosaved games. To turn it on, edit ~/.civctp/userprofile.txt -- I forget exactly which line to change, but it's not hard to find it. The autosaved games in 1.0 don't go where the normal games go (this is fixed in the 1.1 patch).
For those who have been asking, the 1.1 patch is currently in beta testing (though I don't know how many people were chosen for that). I'm one of the testers, and I've submitted about a dozen bugs against the patch -- but many were trivial user interface issues that can probably be ignored (though fixing them would make the game feel more "polished" IMHO).
Saved games are not compatible between 1.0 and the 1.1 patch, so make sure you finish crushing everyone before you apply the patch when it finally does come out. (Since I had to start new games for beta testing the patch, I haven't actually had enough time to do both endings yet; but the military conquest ending worked OK in 1.0, so I suspect it will work fine in the patch. The alien life ending worked fine in the patch, for me.)
If IBM's Visual Age for Java is anything at all like IBM's Visual Age for Smalltalk, you don't want it anywhere near your computer! VAST is far and away the worst commercial program I've ever had the profound displeasure not to be able to avoid installing; it is worse than Microsoft Windows.
VAST uses a graphical install program, so you need X. But wait! That's not bad enough... it doesn't work with anything but the AIX X server, so you can't install it from the PC on your desk. But wait! That's not bad enough, either... it requires CDE. You can't install VAST on a vanilla AIX X workstation -- you've got to install CDE on it just to install Smalltalk.
The VAST installation program is written in Smalltalk. During the installation there are two es. processes that get spawned. They busy-look throughout the whole installation process -- they'll easily chew up an hour or two of CPU time. Most unimpressive. Not to mention the untidiness of all those trailing dots.... "./install." indeed.
On the AIX box, someone has to start up a daemon. This daemon requires a parameter which is a "device number". You get this device number by running another of the VAST programs, which prints the device number on stdout along with some text. So why couldn't the daemon just run this secondary program itself? Yeah, I wrote a simple shell script wrapper to do this, but why should I have had to do this -- this is version 4.5 of a commercial app!
The security is atrocious. In order to stop this daemon, you have to supply the password of the person who started it. That's right -- geteuid() be damned, it won't know I'm root unless I give it root's password. There are two ways you can give it the password -- either as a parameter on the command line, or interactively on/dev/tty. So if you want to stop this daemon at system shutdown time, you either have to embed the password in cleartext in a script, or hire some chimpanzees to make sure VAST is manually stopped before the system is rebooted. I find this completely unacceptable.
Oh, you actually wanted to use Smalltalk? Well, there are bugs galore, and you get to install patches for them. But these patches aren't distributed as standard AIX fileset packages -- oh no, you get to manually move files around and extract tarballs. So, when you ask the AIX package manager what version is installed, it can only tell you the base version, not the actual patch level. I can only conclude that the people responsible for VAST don't know beans about AIX, and think it's just some complex Windoze box.
And of course, you get to type the magic symbols from your secret decoder ring to unlock it. This is one of those licensed products with a built-in enforcer....
Unless IBM can demonstrate to me that VAJava is going to be developed by a completely different group of people than the ones who inflicted VAST upon the world, I'm going to do everything in my power to stop this abomination from dirtying Linux's good name.
You also have to be 'a current DeveloperNet program participant in compliance with all program requirements' including the 'payment of any required license fees'. (I couldn't easily find a reference to 'DeveloperNet', whatever that is, to determine what its 'program requirements' are.) You also may not 'rent, lease, and/or time share the Software'.
There's also the issue of the US export laws (apparently this thing uses encryption), but that's not Novell's fault.
Y'know, it seems that certain companies are just missing the whole point. Either that, or I'm missing the point. Or we have different points of view about what the point is.
From my point of view, it's really really simple. All I want from Novell/Caldera is a way for me (a user running Linux) to be able to read and write files on a Novell 4.x server. 'cause that's where my MS-Mail and cc:Mail always end up.[0]
What that means is, I want Novell to publish the specifications for the Novell 4.x protocols so that the ncpfs people can write a working Linux client.[1][2]
That's all.
Meanwhile, I guess replacing some Novell servers with Linux servers might help a handful of people. I just wish I were one of them.
[0]No, not both at the same time. But at my last three long-term engagements I've been forced to use MS-Mail, cc:Mail and MS-Mail, respectively.
[1]Yeah, sure, the ncpfs client can talk to Novell 3.x servers. And it can talk to Novell 4.x servers which have the bindery emulation turned on. But I'm on the client side! I have no control over what the server does.
[2]Yeah, sure, Caldera has published "Netware for Linux". They've got lots of nifty documentation about how to set up your x86 2.0.35 Caldera Linux system as a Netware server. Where's the documentation on setting up the client? For that matter, where's the client that actually works right? (Let me guess -- Caldera never actually tested the Netware for Linux client side -- they just ran the server and tested it with Windows 95 clients.)
I submitted this story about a week ago when I learned of it through my subscription to a mailing list for Copyright's Commons.
But now that it's been written up in Wired, it's suddenly worth posting?
Hmm....
...why is microsoft not blamed in the proper way ?
on
The Melissa Syndrome
·
· Score: 1
driving against the wall at 150mph, killing people. yeah i know some of you think 'this is something completely different than melissa'. but hell - wheres the difference ?
There are several differences:
The Melissa virus did not kill or harm anyone. This is extremely important -- a lot of people are losing their perspective about this.
The Melissa virus is real, not hypothetical. We can discuss hypothetical situations all day long, but they don't carry nearly as much importance as real situations.
The Melissa virus involves computers, and not cars. A lot of people react differently to computers than they do to cars, despite the fact that the car is an order of magnitude more expensive and arguably more complex and harder to work with. (How many people here could reinstall their operating systems from the original media? How many could rebuild their car from replacement parts, if given all the necessary tools? Now turn these questions around and apply them to the non-computer-savvy people you know.)
I liked the Tylenol analogy the best. Businesses hit by this virus should get together and file a class-action lawsuit against Microsoft for contributory negligence. Even if the lawsuit is settled out of court in secret, or takes years of tedious litigation, the public exposure of Microsoft's gaffes would be a service to the computer industry. And the time to do this is now, while the Melissa virus is still fresh in people's minds. Remember, the outcome of the lawsuit isn't as important as the perception of Microsoft that the lawsuit would create in the public consciousness.
It's about time we (the hacker community) used big business's tactics against them. We don't even have to do much -- just encourage a few upset people to seek justice. And we're not lying or misleading -- we're only telling the truth.
Countersue MS because of how he was caught?
on
The Melissa Syndrome
·
· Score: 1
Correct me if I am wrong, but I am under the impression he was caught because of a string of code, undocumented, added to every word/excel document that takes a user's registration code and system settings and generates a unique id which is then sent out with everything he writes!
Close enough for Microsoft work. According to the news story cited in last week's/. Melissa coverage, the actual tracing was done by comparing the MAC address (a unique identifier on every network card, necessary for networking to work) which was embedded in two documents -- the Melissa virus's host document, and some documents on this guy's web site.
So, the information being inserted by Microsoft Office into your documents is your MAC address (a.k.a. your NIC address, or your ethernet address, or "those funny numbers that your network driver displays when it starts up").
Yes, this is a legitimate privacy issue. If you value your privacy, then perhaps you should not use Microsoft Office.
I got really excited when I saw the headline for this one... but then I went to the site and noticed that, no, they are not releasing the specs for all their protocols -- just some of the protocols.
So I still won't be able to read my MS-Mail(TM) or cc:Mail(TM) from Linux without running a DOS version of MS-Mail or cc:Mail with a Novell Netware client on top of DOS, inside dosemu, will I? It doesn't look like it.
Slashdot Mirror
You've got some spelling errors in there, but that's not necessarily bad -- it may make your message seem more like "the voice of the people". Or something.
Here's mine:
I'm writing to you to express my strong opposition to the proposed Uniform Computer Information Transactions Act (UCITA), which was recently passed by the National Conference of Commissioners on Uniform State Laws. I hope that you will speak and vote against UCITA if/when it is introduced.
Rather than attempt to compile a comprehensive list of all the problems with UCITA (which would be terribly long and boring), I will discuss only the two most serious problems that I see.
The freedom to reverse engineer software must not be denied.
Reverse engineering is simply a fancy way of saying "taking something apart to see how it works". No other product has such draconian laws governing what may be done with it once it has been purchased. As a consumer, I'm free to make such small repairs as I am capable of to other products that I own, or to choose a more qualified technician to make repairs for me -- I don't have to take it back to the original dealer.
But UCITA would put computer software in a special class, with restrictions governing its use in ways that don't affect other products.
In the long run, UCITA may lead to an economic disaster.
By disallowing reverse engineering, UCITA gives total control over software to the people who wrote it. The software cannot undergo independent testing to determine whether it contains any flaws, because all but the most superficial tests would require some knowledge of how the software works (which could be obtained only by reverse engineering).
Without testing, "bugs" in software may go unnoticed for long periods of time, becoming a problem only after the software has been in use just long enough to become indispensable. But because the bugs won't be noticed at first, the software companies will find they have a captive market. There will be no incentive to improve their products or their service. And there will be no competition -- developing a competing product would require reverse engineering the flawed one.
In the short term, this may lead to increased revenues for software companies. But in the long run, the software industry will be dominated by software which is overpriced and which does not work very well. People and companies trying to use this software will end up paying more and getting less in return. Products which rely on the software will fail more often, as the underlying software fails. This leads to a downward spiral which can only end in disaster.
For these reasons, and many others too numerous to mention in this letter, I urge you to OPPOSE any proposed UCITA legislation.
Yes, Bruce's Technocrat.net site is a wonderful thing. For those who missed the earlier story, Technocrat.net is devoted to "technology policy" -- laws which affect technology. It may take a while for the site to become popular, and may go through some growing pains, but if it can actually serve to bridge the gap between computer techies and non-computer techies, it may help educate everyone. (I've learned quite a bit from it already -- I'm quite familiar with the computer-related stories, but I haven't followed the space exploration stories as much, and I didn't know anything about amateur radio.)
I've already submitted a UCITA story to that site. I imagine a lot of other people have, too. I haven't seen one posted yet, but I can't possibly imagine this story not showing up there.
AIX's implementation of LVM is one of the best IMO. Granted, you can't shrink lvs or fs's, but you can increase their size while in full multiuser mode.
Indeed. The Logical Volume Manager is AIX's best feature. It's really good.
AIX can also perform many kernel reconfig tasks without rebooting, as it has a dynamic kernel. The ODM is necessary to support this.
I've found that Linux's kernel has as many, if not more, dynamic features. Installing a newer device driver under AIX does a "bosboot" (which rebuilds the kernel and the boot area) and requires a reboot to take effect. Under Linux, if your kernel is modular, you can recompile a device driver module and then unload and reinsert it without rebooting. Solaris has a similar feature. Also, Linux has a /proc file system (assuming your kernel was compiled with it -- it's the default) which permits on-the-fly parameter reading and writing. AIX does a lot of nifty magic for you, but it's all behind the scenes -- you can't get status information from the kernel through any normal, documented procedures as far as I know.
I don't understand why you think the ODM is necessary for the kernel to do things dynamically. Linux and Solaris have no registry (which is what ODM is -- a binary database of system parameters) and they're just as dynamic as AIX.
'Use the right tool for the job'
Amen.
Actually, can anyone confirm the rumour I've heard that 3.2.5 has some Y2K issues?
Out of the box, yes. I don't know whether there are a full set of Y2K patches for it -- but if so, the list will be pretty damned huge. Here's the y2k_fixcheck output for our last AIX 3.2 system. (We just replaced this box with a larger box running 4.3.2 this weekend, so this 3.2 box is no longer in production. We're keeping it around for a little while though, mostly for reference, as the last production switchover problems are being mopped up.)
******** AIX Year 2000 Update Search Tool ******(v2.2 April 1999)
Starting check. Getting version information.
AIX Version 3 Release 2
Searching update database..........
PTF U444180 for bos.obj not yet applied.
PTF U444250 for bos.obj not yet applied.
PTF U447667 for bos.obj not yet applied.
PTF U447694 for bos.obj not yet applied.
PTF U447704 for bos.obj not yet applied.
PTF U450430 for bos.obj not yet applied.
PTF U450434 for bos.obj not yet applied.
PTF U450435 for bos.obj not yet applied.
PTF U450441 for bos.obj not yet applied.
PTF U450472 for bos.obj not yet applied.
PTF U457945 for bos.obj not yet applied.
PTF U457979 for bos.obj not yet applied.
PTF U458039 for bos.obj not yet applied.
PTF U458063 for bos.obj not yet applied.
PTF U447712 for bosadt.bosadt.obj not yet applied.
PTF U458000 for bosadt.prof.obj not yet applied.
PTF U450447 for bosext1.csh.obj not yet applied.
PTF U458047 for bosext1.mh.obj not yet applied.
PTF U445954 for bosnet.snmpd.obj not yet applied.
PTF U447709 for bosnet.tcpip.obj not yet applied.
PTF U450464 for bosnet.tcpip.obj not yet applied.
PTF U447683 for bsmEn_US.msg not yet applied.
PTF U457956 for bosext2.acct.obj not yet applied.
*********** RESULTS OF UPDATE SEARCH **********
This tool examines the update levels of all installed AIX
filesets for a level the same as or newer than any known
Year 2000 update.
NOT AT LATEST APAR PACKAGE LEVEL
This installation contains filesets which require one
or more of the Year 2000 APAR update packages for this release.
IBM recommends that you obtain and read the AIX Year 2000
Workbook from your IBM representative or from the World Wide Web at
http://www.software.ibm.com/year2000/papers/aixy2
for information on the latest updates for your release.
You may then choose which updates to order and apply
for this installation.
IBM recommends that you regularly check its AIX Year 2000
Workbook for status and information at http://www.software.ibm.com/year2000/papers/aixy2
and the IBM Year 2000 information center for updated status
at http://www.ibm.com/IBM/year2000/
486's was (and is) run by single individuals and maybe small companies - and not heavy industries.
This is demonstrably false. I've administered 486-based Unix systems at major corporations in the past. At one site, they had a Sequent with 12 486DX2-50 processors in it. Yes, twelve. At another site, they had a dual-processor 486 NCR system (but I don't know the clock speed).
These were LARGE manufacturing/distrubtion companies. If you live in the USA, I guarantee you've heard of both of them; in one case, their influence is global. But I can't name them due to privacy considerations, contractual issues, professional courtesy, etc.
Of course, I also realize you're only talking about the server side (even though you didn't explicitly say so). If you count desktop, then I can pretty much guarantee that 95% or more of ALL corporations who have been in business for the last 5 years have, or had, some 80486 processors in house. Most of them probably still have them in service in desktop systems. Where I'm currently working, there are a whole truckload of IBM PS/2 486SX systems still in service. They've got the "Y2K OK" stickers with the black magic marker "X" over top of them to indicate that they're on death row -- but they're still in use! (And a worse piece of desktop equipment you've not seen in many a year, I promise you.... But that's what you get when you're a contractor -- the leftover trash.)
to keep underage children from seeing things that they probably aren't developed enough to see
A 16-year-old isn't "developed enough" to see sex? Many (perhaps most) 16-year-olds have already had sex. The rest have masturbated, most likely with considerable frequency.
One of the biggest problems I see with American media labeling is the implicit connection between sex and violence. You hear the phrase all the time -- "sex and violence", as in "We must protect children from all this sex and violence." But these two concepts have nothing in common apart from their tendency to be lumped together by clueless but well-intentioned moralists.
So how can we change this? What will it take to turn America from a paternalistic morass of enforced morality and uniformity into a viable, healthy land of choice, diversity and self-enlightenment?
Unicenter is a Bad Program. Stay far away!
We have several RS/6000 systems where I currently work. CA Unicenter was loaded on most of them... and for the most part hasn't been a problem. But on one particular machine, we were getting spontaneous "lock ups" (system could not fork() -- ping worked, but telnet would connect and then drop; console login was almost possible but you couldn't get as far as a shell prompt before it crapped out). These "lock ups" would happen after about a week of uptime, with no warning symptoms. We installed an rrdtool-based monitoring system (simple stuff -- load average, active virtual memory pages, etc.) -- there was no sign of danger before the "lock ups" at all.
We sent a crash dump to IBM for analysis. They told us the kernel heap had been corrupted.
We uninstalled CA Unicenter (which for reasons unknown to me loads itself into kernel space like a device driver). The system has been running continously for a good while now:
03:46PM up 17 days, 6:03, 10 users, load average: 0.98, 0.81, 0.48Of course this doesn't prove that CA Unicenter was responsible for the corrupted kernel heap, but we're sure as hell not going to reinstall it!
ObSillyAcronymSubstitution: one of my coworkers here calls them "Computer Assassins".
it allows you to use the software on any machine you own or lease.
Not good enough! I'm a consultant, and so the vast majority of the Unix work I do is for clients. The clients pay for this service. Thus, if I were to install the MagniComp version of rdist, I'd have to have a commercial-use license of some sort.
This is clearly NOT free software.
So, like, I figured I should read this license to figure out what's up. I looked around a bit and eventually found it.
The very first thing I noticed is that it's much, much more difficult for a layman to read and understand than the GNU GPL is. Now, everyone reading Slashdot knows how much controversy, confusion and debate the GPL has spawned -- imagine how much worse it would be if the GPL had been written in this incomprehensible style. The SCSL has no preamble which explains the intent of the license; and in order to make any sense of the text of the license, one must continually refer to the license's Glossary to figure out what is meant by all of the Capitalized Words. The SCSL is actually three or more separate licenses all concatenated together, and you have to read a meta-license to determine which of the sublicene(s) apply to you.
So, while I didn't bother reading all of the license, I got the following out of it:
The software is only free (in the Debian Free Software Guidelines sense) for Research Use. You can't use the software freely if you actually have a job. (The Internal Deployment Use sub-license isn't free, either.)
For any other use (including commercial use), there are unacceptable limitations. You can't distribute modifications, and you can't disassemble or reverse engineer executables.
The last thing I noticed, after I quit reading the license in disgust, was that there was a "session ID" appended to the URL. It seems that Sun wanted to track me as I browsed their site. Naughty Sun! (The actual URL that I got for the license when I finally got to it was http://www.sun.com/jini/licensing/scsl_jcp_v.1.6c_ web.html;$sessionid$E5HGUBAAAV2LDAMU VFZE3NQ -- but I snipped the "session ID" garbage from the end before adding the license link in the first paragraph.
Does Sun really think that programmers are so bone-headed that we won't see right through all of their little tricks? We (or our predecessors) are the people who built the Internet! We aren't stupid, and we notice details. Your lawyers can't bury us with avalanches of mumbo-jumbo, because we programmers will eventually pick our way through the maze and find the rotten trash you dropped at the exit.
By playing these petty little power games with us, Sun only continues to alienate us. This is why Java has met with such a cold reception among the technologically savvy user and programmer community -- Sun doesn't want to play by the rules.
Well, just remember that the ultimate power is ours, not theirs. We have the power to disregard Sun's offerings until they come up with a way to work with us instead of against us. Sun isn't offering anything we need -- they're trying to grow a market. We've already got the tools and the talent to go our own direction, without Sun's poisoned candy. So while Sun keeps shooting itself in the foot and feeding fluff to the "HTML coders", we can go on with our lives.
Too-often refresh. Every page I load is loaded dynamically. I can't think of a reason this would be HTML related, yet it doesn't happen at any other site.
It's not, strictly speaking, as HTML issue. It's an HTTP issue.
When a CGI program emits a page, it emits both HTTP headers (the most important of which is the Content-Type:) and the actual content (typically HTML, or Content-Type: text/html). There are several HTTP headers that can be used to control the caching behavior of browsers and proxies -- Expires: is probably the most powerful, but Last-Modified: is often easier to use correctly (depending on the content).
If you're in Netscape, check out the various details under View | Page Info. It's rather informative about the aging information.
When in doubt, if you're serious about your CGI development, you can telnet to the web server and issue HEAD commands manually to get the HTTP headers for your pages. Unfortunately, it's not at all easy to get the precise behavior of cookie-enabled sites (like Slashdot) doing this, since you'd have to manually encode and ship your cookie too....
Slashdot seems not to use any of the aging headers when logging on to the main page as a cookieless coward:
Tcl is a highly successful open source porduct which is now making money for its authors through the company they set up, Scriptics.
"Successful" by whose definition? If "successful" means "profitable", then yes, I suppose it was successful. But some of us do not measure success by the amount of money brought in. As a language, Tcl leaves many things to be desired (from what little I've seen of it), so by my own personal standard it is not a success.
The real driving force behind the GPL flame wars (like this one) is a conflict between philosophies. On one side, we have people who cannot understand motivations other than profits. On the other, we have people who are primarily motivated by things other than profits; but these people often fail to understand that there are people for whom money is more important than anything else.
In the middle, there are all the rest of us who try our best to explain things to both sides. :-(
couldn't be bothered writing 'su' and then a lengthy password every time he wants to play Quake
chmod 1777cat >/usr/local/bin/squake <<EOF
#!/bin/sh
cd
exec
EOF
chmod 755
You'll probably want to do the same for the "hipnotic" and "rogue" directories, and make similar wrappers for the other quake binaries. Shame on id for not writing a better installation script.
(Sorry about the first one. I honestly thought the Preview button was on the left, not the right, and clicked Submit too fast.) :(
couldn't be bothered writing 'su' and then a lengthy password every time he wants to play Quake
chmod 1777You'll probably want to do the same for the "hipnotic" and "rogue" directories, and make similar wrappers for the other quake binaries. Shame on id for not writing a better installation script.
couldn't you just comment that some portions of the code are LGPLed and the rest is GPLed[?]
No, you cannot. Section 1 of the GPL says this:
When you combine GPL'd code with any other code to form a single work, the resulting work must be distributed under the terms of the GPL if it is distributed at all. (You may use the work yourself without ever revealing the source code, but you can't share or sell your work without sharing the source code.)
I think it would be an exceedingly unusual person, however, who couldn't be persuaded to switch WP programs for some sum of money.
You've never seen a full-blown vi vs. emacs war, have you?
The CTP graphics are 16 bits. If your X server is running in 24-bit or 32-bit mode, then the graphics are converted on the fly, and the game will be much, much slower than if your X server is running in 16-bit mode. Try restarting X in 16-bit mode.
My serial port trackball doesn't work well with CivCTP for Linux. It works fine with all other X software I've used, but with CivCTP it jitters and shakes.
I haven't seen precisely that problem, but I can point out two possibly related issues:
Problem #4: None of the symbolic links placed all over my filesystem worked.
This is a known problem. The symbolic links that are created by the installation script point to the wrong location. You can manually fix them to correct the problem. But I can understand how this could be confusing for Linux newbies.
Problem #7: This is the big one. After many hours of gameplay, the game burps. Segmentation fault. This has happened to me three times in a row. Seems to happen after many hours of play, but I haven't been watching memory or anything to know if there is a leak.
The game definitely leaks memory. You'll probably want to save and restart your game every few hours (depending on how quickly you play and how much RAM you've got -- your 64 MB is the same as mine, so you'll probably notice some thrashing after several hours of game play).
The upcoming patch is supposed to address some of the crashes that people have seen. (I haven't seen any crashes yet except for the alien life form ending.)
There is actually an autosave feature in CTP, though it's undocumented and unsupported in 1.0 and requires manual intervention both to turn it on and to get at the autosaved games. To turn it on, edit ~/.civctp/userprofile.txt -- I forget exactly which line to change, but it's not hard to find it. The autosaved games in 1.0 don't go where the normal games go (this is fixed in the 1.1 patch).
For those who have been asking, the 1.1 patch is currently in beta testing (though I don't know how many people were chosen for that). I'm one of the testers, and I've submitted about a dozen bugs against the patch -- but many were trivial user interface issues that can probably be ignored (though fixing them would make the game feel more "polished" IMHO).
Saved games are not compatible between 1.0 and the 1.1 patch, so make sure you finish crushing everyone before you apply the patch when it finally does come out. (Since I had to start new games for beta testing the patch, I haven't actually had enough time to do both endings yet; but the military conquest ending worked OK in 1.0, so I suspect it will work fine in the patch. The alien life ending worked fine in the patch, for me.)
If IBM's Visual Age for Java is anything at all like IBM's Visual Age for Smalltalk, you don't want it anywhere near your computer! VAST is far and away the worst commercial program I've ever had the profound displeasure not to be able to avoid installing; it is worse than Microsoft Windows.
Unless IBM can demonstrate to me that VAJava is going to be developed by a completely different group of people than the ones who inflicted VAST upon the world, I'm going to do everything in my power to stop this abomination from dirtying Linux's good name.
You also have to be 'a current DeveloperNet program participant in compliance with all program requirements' including the 'payment of any required license fees'. (I couldn't easily find a reference to 'DeveloperNet', whatever that is, to determine what its 'program requirements' are.) You also may not 'rent, lease, and/or time share the Software'.
There's also the issue of the US export laws (apparently this thing uses encryption), but that's not Novell's fault.
Oh, gee, look -- another server-side solution.
Y'know, it seems that certain companies are just missing the whole point. Either that, or I'm missing the point. Or we have different points of view about what the point is.
From my point of view, it's really really simple. All I want from Novell/Caldera is a way for me (a user running Linux) to be able to read and write files on a Novell 4.x server. 'cause that's where my MS-Mail and cc:Mail always end up.[0]
What that means is, I want Novell to publish the specifications for the Novell 4.x protocols so that the ncpfs people can write a working Linux client.[1][2]
That's all.
Meanwhile, I guess replacing some Novell servers with Linux servers might help a handful of people. I just wish I were one of them.
[0]No, not both at the same time. But at my last three long-term engagements I've been forced to use MS-Mail, cc:Mail and MS-Mail, respectively.
[1]Yeah, sure, the ncpfs client can talk to Novell 3.x servers. And it can talk to Novell 4.x servers which have the bindery emulation turned on. But I'm on the client side! I have no control over what the server does.
[2]Yeah, sure, Caldera has published "Netware for Linux". They've got lots of nifty documentation about how to set up your x86 2.0.35 Caldera Linux system as a Netware server. Where's the documentation on setting up the client? For that matter, where's the client that actually works right? (Let me guess -- Caldera never actually tested the Netware for Linux client side -- they just ran the server and tested it with Windows 95 clients.)
I submitted this story about a week ago when I learned of it through my subscription to a mailing list for Copyright's Commons.
But now that it's been written up in Wired, it's suddenly worth posting?
Hmm....
driving against the wall at 150mph, killing people. yeah i know some of you think 'this is something completely different than melissa'. but hell - wheres the difference ?
There are several differences:
I liked the Tylenol analogy the best. Businesses hit by this virus should get together and file a class-action lawsuit against Microsoft for contributory negligence. Even if the lawsuit is settled out of court in secret, or takes years of tedious litigation, the public exposure of Microsoft's gaffes would be a service to the computer industry. And the time to do this is now, while the Melissa virus is still fresh in people's minds. Remember, the outcome of the lawsuit isn't as important as the perception of Microsoft that the lawsuit would create in the public consciousness.
It's about time we (the hacker community) used big business's tactics against them. We don't even have to do much -- just encourage a few upset people to seek justice. And we're not lying or misleading -- we're only telling the truth.
Correct me if I am wrong, but I am under the impression he was caught because of a string of code, undocumented, added to every word/excel document that takes a user's registration code and system settings and generates a unique id which is then sent out with everything he writes!
Close enough for Microsoft work. According to the news story cited in last week's /. Melissa coverage, the actual tracing was done by comparing the MAC address (a unique identifier on every network card, necessary for networking to work) which was embedded in two documents -- the Melissa virus's host document, and some documents on this guy's web site.
So, the information being inserted by Microsoft Office into your documents is your MAC address (a.k.a. your NIC address, or your ethernet address, or "those funny numbers that your network driver displays when it starts up").
Yes, this is a legitimate privacy issue. If you value your privacy, then perhaps you should not use Microsoft Office.
Who uses Novell anymore?
Everyone, dammit! :-(
I got really excited when I saw the headline for this one... but then I went to the site and noticed that, no, they are not releasing the specs for all their protocols -- just some of the protocols.
So I still won't be able to read my MS-Mail(TM) or cc:Mail(TM) from Linux without running a DOS version of MS-Mail or cc:Mail with a Novell Netware client on top of DOS, inside dosemu, will I? It doesn't look like it.