Biometric password systems have problems, but perhaps if you were to couple them with a simple password (which dopey users can remember) then you would have something more secure than just a simple password...
Speaking of passwords, where I work now the password policy is requires minimum of 6 characters, >=1 upper case character, >= 1 lower case character, >=1 numeric character *and* they're changed every 40 days. Probably one of the better password policies I've ever seen enforced.
Just an opinion... Even if you don't get a degree in computer science, MIS or engineering, you're better of with any 4 year degree than none at all.
Case in point: I used to work in a shop that didn't require a college degree. "Offically" everyone paid the same regardless of schooling (beyond high school). "Unofficially", those folks that had 4 year degrees or graduate degrees were promoted faster and paid better than the folks with no degree or a 2 year degree...
I started, fresh out of college at a higher pay rate than guys that had been there 2-3 years. So skip the school, but keep in mind, you'll have to "do your time" one way or another.
[pulling on asbestos suit] Yikes. Guess someone forgot to mention this is a non-smoking thread.;)
FWIW, I'm not in Washington. To the best of my knowledge, they have yet to setup remote DSLAMs in Minnesota - the running excuse has been that providing equal access is "too expensive" (At least that is the story from the QWest contractor at my office.) With the competition removed, at very least they'll have to change their story.
Maybe in the short term they will reduce their DSL services, but I don't think that they want to loose ground to the cable providers either. Eventually they'll have to grow their service, or exit the broadband business...
I'm a current QWest customer and hate every minute of it (don't have much choice for BB service) I cringe at the thought of seeing QWest's cesspool grow any larger than it currently is. However, I think there may be a "silver lining" to this cloud (at least depending on your point of view). QWest currently concentrates their DSL equipment in the CO because they have to allow equal access to that equipment. If that equal access went away, they could move the DSL equipment further from the CO to smaller unmanned stations and extend the range of DSL services to areas where coverage isn't currently provided.
While it might push some competition out (what competition is there anyway?) bringing broadband to outlying communities would be a plus...
I work for a rather large international bank and I can say we've been moving away from Microsoft as fast as you can say "dot net". From what I've seen this is true of many of the other firms in the financial sector as well. I suspect a large part of the reasoning is not the superiority of Java, but rather is the "anything but Microsoft" syndrome in effect. I seriously doubt that C# will be considered here as a replacement for Java any time soon.
I have a feeling that C# will be adopted by Microsoft's technology partners, but why would any firm that has spent time and money moving away from Microsoft products go running back because of a new product offering? Its not the products we're trying to get rid of, its the company.
I suppose this is somewhat because I have nothing better to do at work...
I reply to the sending address with a spoofed email from the mailer daemon account (daemon@somedomain.com) and include a legitimate looking "undeliverable" message in the body. Most spammers are too dumb to realize that the message is spoofed and they'll remove you from their list to avoid getting tons of bounced messages when they unleash their next wave of "marketing"
Unfortunately this doesn't work well for the type of messages that contain nothing more than a bogus email address and a website link, but I like using it as a first attempt none the less...
I'm right there with you on the resource management problems... Visual Age requires a *lot* of resources. However, I'm running VA/J on Win2k at work, so I haven't seen the problems you speak of with Win95. I can't really comment on the Linux version because I've only seen it running, but have never set it up myself (my poor Linux box at work just doesn't have the horsepower)
As for not seeing the entire class... I think that is actually one of the nicer features of VA/J. The intent is that each method (and attribute) within a class is treated as if it were a separate file, making it easier to deal with large objects. I must admit at first I hated it (VA/J was forced upon me by my employer) and ran back to vim with syntax highlighting, but once I figured out how to navigate about VA/J, I actually began to appreciate the layout.
I would guess there are better java IDEs out there, but VA/J seems to have fairly large user base and I don't have a lot of choice in the matter, so I figured I'd give my $.02 on it.
My choice amongst the commercial IDEs is IBM Visual Age for Java.
Pros
Easy to use
Reasonably priced (~$250 for the professional version)
Supported on multiple OSes (Windows, OS/2, Linux, Aix)
Can hook into external code repositories such as Visual Source Safe or PVCS
Nice debugger
Seems to be popular amongst IT shops where technology is not their primary product.
Cons
Enterprise version is quite a bit more expensive. ($3,000 + $150/seat)
Kind of bloated (256MB of RAM and 1GB of disk required for Windows version)
A little "pokey" (reportedly written in SmallTalk...)
The layout takes a while to get used to
Enterprise Builder makes heavy use of proprietary IBM classes
Ironically one of the easiest ways to cut costs in the short term becomes very expensive in the long term. My experience seems to be consistent with that of others: The QA department is staffed with bottom of the barrel technologists who don't understand what it is they are doing and aren't paid much to do it.
Hopefully many companies (not just Apple) will learn a lesson from this little blunder. The QA process should, in many respects, be larger than the development process. Many companies have the notion that good developers alone can produce good products. IMHO, most good products have good developers and great QA folks behind them.
Byte.com is pretty non-responsive from my part of the world. Its a good read if you have time...
Linux Kernel Pillow Talk
(Linux Kernel Pillow Talk:
Page1of1)
By Moshe Bar
October 29, 2001
And you thought the netherworlds of dry kernel engineering were
free of politics, egos, and prima-donnas? Guess again. The events of
the last four to six weeks and the e-mails flying to and from the
Linux kernel mailing list show how Byzantine and complex the dynamics
of decision finding, features design, and implementations can be. Go
to http://www.tux.org/lkml/ to
subscribe to the kernel mailing list, but be careful: This is a very
high-traffic list. Subscribe only if you really want to follow every
single detail of the Linux kernel, or instead read the weekly digest
at Linux Kernel Cousin at http://kt.zork.net/kernel-tra
ffic.
Sure, the lively debates have always existed. In the past there
have been disputes about the Linux firewalling code, networking code,
scheduler, installer, driver model, and many more. One recurrent theme
has always been the Virtual Memory (VM) manager. Nothing determines
the peculiar behavior, the feel -- even the ultimate success or
failure of an operating system -- like its virtual memory design.
Sometime during the development cycle leading up to the Linux 2.4.0
kernel, in other words in 2.3.xx times, Rik Van Riel (http://www.surriel.com), a Dutch
kernel hacker working for Brazil-based Conectiva (one of the smaller
Linux distributions), introduced a radically new VM code. It was based
on what seemed to be new and advanced algorithms for efficient
finding, allocation, and disposal of virtual memory pages requested by
programs. Rik later introduced an interesting new kernel feature
called the "OOM killer." OOM stands for Out Of Memory. The OOM killer
attempts to locate a killable process when memory runs out in the
system. Without such a feature the whole machine can go nuts or enter
a vicious cycle of swapping out a few pages, realizing immediately
after that those pages are needed, and searching again for swappable
page candidates, keeping the kernel busy doing only this instead of
letting user processes run.
Rik is a gifted hacker, and among other things he has been trying
to improve the efficiency and speed of maintenance of those lists in
the kernel responsible for managing all the virtual memory pages in
the system. One of the main questions to address in every operating
system VM code is: "How do you choose which page to steal next when
there is a RAM shortage?"
In the 2.4.0 release, the Linux kernel scans the process page and
decides which page to remove. The problem with this approach is that
sometimes a lot of process tables have to be scanned to free just one
page, or very few pages. Also, this approach does not guarantee that
the pages stolen are only those that will not be needed again very
soon. Some UNIXes introduced the notion of the working set; that is,
the minimum amount required by a process to function efficiently. This
solution is, however, limited to per-process pages only and does not
consider other kinds of pages, such as filesystem caching. Stealing
from these pages might in some cases even prove counter-productive.
Very often in VM theory, a solution to one problem can worsen another;
that's why kernel programming is difficult.
Rik van Riel and I have variously discussed another approach,
called "reverse mapping," which implements a reverse-lookup between
the page and process table. Once you have reverse-mapped pages, the VM
can simply scan the pages for the ones to be freed. Naturally, some
extra fields need to be added to the appropriate control tables to
allow this reverse mapping. My own implementation has an overhead of
14 bytes and is therefore certainly a lesser solution than Rik's
-- his overhead is just 8 bytes.
Other extremely talented kernel hackers such as Marcelo Tosati and
Ben LaHaise have made other important contributions to the Linux VM.
However, even though all these intelligent people tried hard to
make the Linux VM fast, efficient, and powerful, user reports since
the 2.4.0 release indicated poor Linux kernel performance and erratic
and unstable behaviors. Up to kernel 2.4.7, for instance, on machines
with small memory footprints (less than 40-MB RAM), sudden swap storms
could erupt which would virtually freeze the system while it
inexplicably started swapping pages in out and like crazy. In some
cases, the aforementioned OOM Killer would choose the wrong process to
kill; I have seen the all-important init process killed
erroneously. Many fringe kernel projects, like my own Mosix project or others such as
Win4Lin, suffered because users accused these projects of unstable
operations, assuming that a released kernel like 2.4.0 must be free of
such nasty bugs. Even though the kernel had gradually evolved from
2.4.0 to 2.4.9, it was evident that the VM design was more of a
liability than an advantage.
Linus himself said in a recent kernel list mailing that he wasn't
happy yet with the VM. These problems were enough for many Linux shops
to resist the migration to the 2.4 kernels and instead continue using
the 2.2.19 kind of kernels. Obviously, compared to 2.4., the 2.2.
series has many shortcomings -- like no zero-copy networking, the
division of page cache and buffer-cache in filesystem operations, big
spinlocks (serializations of kernel execution paths for computers with
more than one CPU) for many parts of the kernel, and so on.
A simple C program like the one below shows how kernels up to 2.4.9
had problems dealing with stress workloads on the VM system. If, after
running this program, you turned the swap partition off with swapoff,
your server or workstation would become totally unresponsive for up to
15 minutes.
/* based on a code originally proposed by Andrew Tanenbaum,
later by Derek Glidden and many others since */
#include
void main(void) {/* in the next line we allocate 200MB, but since the virtual
memory page is not actually allocated by the kernel until we
use it, we also have to create an access to. The amount of
allocated pages should reflect the total RAM on your
computer. This test runs well with machines of, say, 256MB */
void *p = (void *)calloc(50000000, sizeof(int)) ;/* In the next line we let the system calm down a bit after
allocating pages*/
sleep(12);/* and now re release it all again */
free(p);
}
Back in February 2001, I ran an informal and unscientific benchmark
comparing FreeBSD 4.1.1 to kernel 2.4.0 (visit http://ww
w.byte.com/documents/s=558/byt20010130s0010/) on exactly the same
hardware and with exactly the same subsystems versions (MySQL,
Sendmail, Apache, and others). The results clearly showed that,
indeed, there were major problems with the efficiency and speed of the
early 2.4 kernels.
A New VM
Then, on September 24, with the kernel standing at version 2.4.9,
everything suddenly changed. Andrea Arcangeli, an Italian kernel
hacker (read my interview with him two years ago at http://ww
w.byte.com/documents/s=287/byt20000229s0008/) and a very prolific
contributor, decided that enough was enough. He sat down and in one of
those marathon hacking bouts completely rebuilt the VM from
scratch. In short succession he sent to Linus Torvalds over 150
patches to the 2.4.9 kernel, to implement a new VM engine. This is an
extremely remarkable feat. A VM is a major piece of software and by
nature very complex. One needs to satisfy many opposed objectives:
Simultaneously efficient handling for server-type loads and
interactive-type loads; ease of implementation and at the same time,
optimized use of every last and small feature of the CPU. The VM must
also be able to run well on Intel CPUs spanning 4 or 5 generations, as
well as on AMD chips, Alphas, MIPSes, Sparcs, ARMs, and what have you.
Andrea, by the way, does all his development on a Compaq AlphaServer
with 2 500-MHz CPUs and 3-GB RAM.
Out of the blue, Linus accepted the new VM and incorporated it into
the official Linux kernel tree.
Recently, I spent two days with Andrea giving speeches. During the
two days, over many bottles of beer, we had plenty of time to discuss
his new VM. I was mainly interested in how the new VM affects Mosix.
Because Mosix must migrate virtual memory pages belonging to the
program's address spaces between cluster nodes, it is important to
correctly understand the VM and interface efficiently to it.
Specifically, Andrea took exception to the following problems in
the 2.4 VM:
kswapd looping forever on DMA or NORMAL class-zones.
swap+ram will be almost all available address space (modulo when
the swap cache serves to avoid swapin of shared anonymous memory after
a fork).
swapout storms.
benchmarks, when run repeatedly, gradually slow down.
The new VM is much simpler and faster. Let me explain how it works.
The old 2.4 VM had a major design problem that manifested itself
mainly when freeing physically dirty pages (remember dirty pages are
the frames of 4-KB memory in the RAM whose contents have been modified
by one of the virtual memory pages residing in it). The last owner of
the page (usually the VM, except in swapoff) has to clear the
dirty flag before freeing the page. When being swapped off in
swapoff it may be a little more complicated -- we may
need to grab the pagecache_lock to ensure nobody starts using
the page while we clear it.
So, Andrea went and did the following: All physical pages are now
divided into active and inactive pages. These two are further divided
into dirty and clean for both active and inactive. When the active
dirty pages become about 66 percent of the total number of pages, the
VM starts to scan them for the oldest ones to be put into inactive
dirty and then, later still, from there to the swap when memory
becomes tight. This part is very central to the new VM and its
simplicity is...well, simply stunning.
This elegant mechanism totally changes the behavior of the 2.4.10
kernel under heavy load and also makes for much better predictability
of the system. Another very important change is that the swap is now
additional to the RAM, just like in 2.2 times. All earlier 2.4 kernels
(since 2.3.12) needed at least the same amount of RAM in swap and then
more to give you additional virtual memory. This meant that on an 8-GB
server, you needed to put aside almost a full 9-GB disk just to be
able to swap, similar to some versions of Solaris or other UNIXes.
Finally, the page scanner doesn't page scan if there are
theoretically no freeable pages, whereas before it did. Oh, and the
OOM killer never really worked, so Andrea disabled it, as I did for
all my kernels. In 2.4.12 it is enabled again; this time, however, it
works much better. Try it with the above program to see it in action.
Arcangeli's VM is stable, acts predictably -- something that
the old VM never really achieved -- and it makes the swap space
look like it did in 2.2 days. Additionally, the design is much simpler
and easier to understand. People will catch up fast with it.
However, many kernel hackers disagree. Upon the release of kernel
2.4.10, a virulent and sometimes aggressive debate flamed up, with
many people trying to show why one of the two was a good VM and the
other not. Some comments got a bit out of control, and only in the
last two weeks or so has some calm been restored.
However, one nasty side effect stays. Alan Cox, the number two man
after Linus Torvalds, does not yet like the new VM and in his own
kernel tree (called the "ac tree") he still continues to use and patch
the old VM. As a consequence, users and system administrators now find
themselves facing two very different kernel trees to choose from: the
official Linux tree and the Alan Cox tree. Quite often, latest patches
to drivers and new features are only in Alan Cox's tree. Those who
want to go with the official Linux source code may find themselves
unable to apply the patches due to the different VM code all over. It
is acceptable for the two trees to be different for a few days on such
important subsystems like VM, but it is not acceptable to have them
different for months and across many kernel versions.
Nobody has yet dared to speak of a Linux source fork, but this is
dangerously close to one.
It became obvious that the VM up to 2.4.10 was a design liability.
You can try to fix something that was designed badly, but it will
never become a beauty. I think Linus' decision to scrap the old VM and
go with the Arcangeli VM was courageous and right. Having a
functioning and stable Linux box should not be deferred to 2.5 when we
can do it already with 2.4.
Kernel Preemption
But apart from the VM issues, there are other lively debates in the
kernel community. There was an interesting interview at h
ttp://kerneltrap.com/article.php?sid=328&mode=thre ad&order=0 with
Robert Love, who is leading one of two projects trying to make the
Linux kernel fully preemptible. Making the kernel preemptible means
making it possible to interrupt whatever the kernel is doing (say,
executing a system call) to process some other outstanding task and
then return to its original task. Linux, as a multiprocessing OS,
obviously always did that for user-land processes. However, many, just
like Robert Love, feel that the fact that Linux up to now would not
let itself be interrupted contributed to poor latency. Latency
describes how quickly you can expect a response from your kernel when
you actually need something from it. Note that Linux is not designed
as a real-time OS (though there is at least one Linux real-time
implementation somewhere), and therefore does not explicitly guarantee
latency. User-land programs must be aware of this as, especially with
kernel preemption, latencies can be very unpredictable.
Theoretically, an OS will answer faster if it can be interrupted.
What does suffer from kernel preemption is the global throughput. If
you have a task that gets n seconds within the kernel to
complete (let's say executing a given system call takes 0.005
seconds), then all the interruptions add some overhead to switch from
one kernel task to another. So, finishing the execution of that system
call (in our example) will finally require n+op where
p is the frequency of switching and o the static
overhead for one switching operation. Notice that kernel context
switching does not invalidate the CPU cache, and is therefore not as
expensive as process switching. However, kernel preemption will surely
lead to a higher rate of switching from kernel space to user space,
because upon preemption the scheduler might decide to give higher
priority to a user process.
In other words, kernel preemption does decrease latency but slows
down overall throughput. It's the math: nothing to be done against it.
Furthermore, in his interview, Robert Love heavily criticized Linus
Torvalds for adopting Andrea Arcangeli's new VM in 2.4.10 and dropping
the old van Riel VM.
Well, I did try the patch with kernel 2.4.12 and with pre13. While
accurate measurement (which Robert Love provides with the preemption
kernel patches) does indeed report an improvement in latency, for the
life of me I have not noticed it on an empirical basis.
I really do appreciate Love's work, but I do not fully agree with
some of his comments in the interview. First, as Linus himself said,
if latency sucks in the kernel then we should check why it sucks, with
or without preemptive scheduling. If the latency is bad in the stock
kernel, then it should be fixed anyway.
The preemptive kernel 2.4.12 worked fine on my laptops and on my
SGI 550 workstation where I do interactive work. The MP3 player very
rarely skipped beats when doing heavy background work such as kernel
compiling or opening large files in the editor. But for my servers and
clusters, the decrease in performance and the unpredictability of
latency is a problem. Also, some important patches will not apply to a
Love-patched kernel. Mosix, the clustering kernel extension, does not
patch correctly, and neither do some versions of the LIDS intrusion detection system.
It is up to each individual user to decide whether or not to use
the patch, but is important to understand the implications of using
it.
Linux and FreeBSD Revisited
Upon returning home the other week after meeting with Andrea, I
went to my lab and searched for the disk images of the server
comparison I ran back in January of this year (of FreeBSD 4.1.1 versus
Linux 2.4.0). I took the Compaq ML500 server I have been reviewing (2x
1-GHz CPUs, 2-GB RAM) and upgraded both the FreeBSD disk image to
4.4-Stable and the Linux version to 2.4.12. Then, I changed the memory
down to 192-MB RAM so as to stress the VM system more. I also upgraded
to the latest stable versions of Sendmail (8.12.1) and MySQL (version
3.23.42). Finally, I compiled everything with the latest version of
gcc, 3.0.2, and tuned the two instances to the best of my knowledge
(softupdates and increased maxusers for FreeBSD, and untouched default
values for Linux).
The results were very interesting indeed. Since this benchmark is
too much to be handled in this article, Byte.com will post it here
soon for you to read.
The story of this article is that the 2.4 kernel has finally grown
up with the 2.4.10 release. Not many users outside the relatively
small kernel community realize that. Now you know about it, too.
Spread the good news and immediately install 2.4.12 on your busy
server. The server will thank you for it.
Moshe Bar is a systems administrator and OS
researcher who started learning UNIX on a PDP-11 with AT&T UNIX
Release 6, back in 1981. Moshe has a M.Sc and a Ph.D. in computer
science and writes UNIX-related books.
For more of Moshe's columns, visit the Serving With LinuxIndex Page.
Page1of1
That making strong encryption illegal is going to stop criminals from using it?
Better yet, how would it be enforced since there is already so many strong algorithms out there? I can see it now...
AP NEWS...
Building off the success of past handgun buyback programs, the new FBI announced today their latest effort in the war on crime, "Cash for Crypto", where computer users can turn in dangerous cryptographic software for $100 cash, no questions asked. Contact your local spook for details.
Good point, but how many MP3 whores really use SCSI anything? When you can get a 60GB IDE drive for under $200 vs. more than $400 for the same capacity in SCSI the choice is fairly clear. Especially for someone on a limited income (which clearly MP3 whores are, or they'd just buy the damn CD!)
Besides a faster drive still only masks the real problem...
Has anyone ever tried to move large amounts of data (say, a couple MP3s at 5MB each) from a windows share using anything less than a high-speed LAN? Unlike FTP, SMB is far from speedy and is painfully slow even on a LAN (especially considering the alternatives.) This might work in limited applications, but for the most part I'm thinking the speed would be unbearable no matter how much bandwidth you have at your disposal. Scale it up to a couple hundred users and it'll be worthless.
Bush: I've been in a war and done drugs. Personally I think war is bad, so we should just stop doing it.
Gore: I personally drove 60 elderly people in a bus to Canada to help them get their prescription drugs. I think we need to roll our tanks into Canada and take all their drugs.
2) Minority Religions...
Bush: I think as long as law abiding Americans believe in God and Jesus Christ our savior that they should be protected from persecution by the government.
Gore: I have no problems with Minorities or their religion. As a matter of fact I was just having coffee with some of my Chinese friends not that long ago where we were discussing God. They seemed a bit unclear about Jesus' role in things, but I'm sure they were just pulling my leg. Everyone believes in Jesus, right Joe? Tipper and I also proud to have a number of minority acquaintances. Our maid, our chauffer and our nanny...
3) Why give a tax cut?
Bush: I have some friends... Lets call them "major campaign contributors" for lack of a better word. They pay an astonishing $500,000 a year in taxes. Don't you think we should give these poor folks back some of that hard earned money?
Gore: I favor a tax cut. We should cut taxes but only for the poor. The wealthy people in this world can afford taxes so I'm in favor of a 50% tax cut for those people that are paying less than $200 in taxes annually.
4) electoral reform
Bush: I fully support the death penalty. If there is a problem with the electoral system, I say hire an electrician.
Gore: I say down with the third party - the third party is merely pulling away attention from the primary candidates (Nader supporters: Wake up, he doesn't stand a snowball's chance in hell. Vote for me!)
5)How Do You Feel About Intellectual Property?
Bush: Uh.... Well, I try to leave all my property dealings to the my real-estate agent. You might want to check with her.
Gore: Ever since I invented the Internet I've had strong opinions about this subject. Who does this Tim Berners-Lee guy think he is anyway? Companies and people should be able to lock their ideas up tighter than my lips on Clinton's ass. I mean, an idea is something that can't possibly be had by more than one person right? So clearly whoever thought of it first should retain full rights and get paid lots of money.
6) Encryption....
Bush: Its clear to me that no law abiding citizen has any need for encryption. American families should need to hide stuff from each other. We need to strengthen our families and foster brotherhood and friendship amongst all God fairing people under the watchfully eye of our savior Jesus Christ.
Gore: I don't see what the big deal is; some people want to be cremated, others want to be buried. If you want to be encrypted then so be it. Now one thing that we should address is international trade. I think it's a travesty that we're banning the export of American made strong crypts. We make some of the finest products in the world and I think we should vigorously pursue the open exchange of these products with our foreign friends who are passing on to the next world.
7) Rising Political Protests
Bush: My personal stock portfolio has seen a 153% gain in the past 5 years thanks to corporate interests. I think these folks are just sore because they didn't get a piece of the pie.
Gore: Yeah! What he said!
8) Asteroid Defenses
Bush: I'm all for military spending. Lets just build one really big missile and blast those asteroids into outer space.
Gore: Well, I'm no doctor, but I believe there are a number of discrete inexpensive treatments for asteroids that can be purchased at your local Walgreen's.
9) The Future of the Country, and of Humanity
Bush: Well this campaign really isn't about young people. However to address the aging population: I'll help you get your prescription drugs so your remaining years can be nothing but a pain free drug induced haze.
Gore: I must say that I am very concerned about the future of this country for all elderly people and undecided single female voters. I will promise anything you want to hear in order to get your vote back from that bastard Nader!
While Windows ME is clearly an upgrade to 98 and you have a very good point regarding the architectural differences, there is still more to Windows ME than just "98 with no boot-to-dos functionality and the W2K shell." There is a number of other components that were taken from Win2k besides the shell. Thus my statement that it was more like a stripped down version of Win2k than an upgrade of 98.
If you'll recall M$ had claimed at one point in time that Win98 would likely be the last "home" OS and that their home OS (Win9x) and business OS (WinNT) would converge with the release of Win2k (ha ha, yeah right!) Windows ME is just another step towards that goal.
Even though ZDnet doesn't carry the most accurate, non-biased reviews, they do have a review of Windows ME that offers a bit more insight into the architecture, how it differs from Win98 and Win2k(http://www.zdnet.com/pcmag/stories/pipreview s/0,9836,176419,00.html)
What I've heard from some of my co-workers that are on the MS Beta program: "Windows ME is essentially Win2k pro with the 98 kernel (for legacy device support) - it isn't a beefed up version of 98, its a stripped down version of Win2k." Since WinNT3.51 there hasn't been drop to dos type functionality, so it should be no surprise that its absent from ME.
So my roommate and I were mulling this over and best we can tell they have a bunch of ugly looking JScript to create a fairly complex (obscure) encryption scheme. When you start to look at it a little closer it apears to be nothing more than a XOR of the encrypted winning URL(s) with an encryption key. The key is generated using the 16 character login, 4 character password and a little math...
They do kind of throw us a bone however - the first 7 characters of the plain text are know to be 'http://' they check for this in the JScript. You could also be bold and guess that the next 15 characters are www.kipling.com That leaves 44 (web-address leagal) characters to brute force search.
Even though we are only searching web legal characters (about 101?) this is still a ugly problem to brute force. But if anyone has a spare supercomputer laying around you could definatly piss off some folks at Kippling by cracking this puppy and posting the winning URL for a true test of the slashdot effect. >:)
Slashdot Mirror
Biometric password systems have problems, but perhaps if you were to couple them with a simple password (which dopey users can remember) then you would have something more secure than just a simple password...
Speaking of passwords, where I work now the password policy is requires minimum of 6 characters, >=1 upper case character, >= 1 lower case character, >=1 numeric character *and* they're changed every 40 days. Probably one of the better password policies I've ever seen enforced.
Just an opinion... Even if you don't get a degree in computer science, MIS or engineering, you're better of with any 4 year degree than none at all.
Case in point: I used to work in a shop that didn't require a college degree. "Offically" everyone paid the same regardless of schooling (beyond high school). "Unofficially", those folks that had 4 year degrees or graduate degrees were promoted faster and paid better than the folks with no degree or a 2 year degree...
I started, fresh out of college at a higher pay rate than guys that had been there 2-3 years. So skip the school, but keep in mind, you'll have to "do your time" one way or another.
for those of us who live in rural areas to be able to get something other than the local news (aka the nightly farm report)
[pulling on asbestos suit] Yikes. Guess someone forgot to mention this is a non-smoking thread. ;)
FWIW, I'm not in Washington. To the best of my knowledge, they have yet to setup remote DSLAMs in Minnesota - the running excuse has been that providing equal access is "too expensive" (At least that is the story from the QWest contractor at my office.) With the competition removed, at very least they'll have to change their story.
Maybe in the short term they will reduce their DSL services, but I don't think that they want to loose ground to the cable providers either. Eventually they'll have to grow their service, or exit the broadband business...
I'm a current QWest customer and hate every minute of it (don't have much choice for BB service) I cringe at the thought of seeing QWest's cesspool grow any larger than it currently is. However, I think there may be a "silver lining" to this cloud (at least depending on your point of view). QWest currently concentrates their DSL equipment in the CO because they have to allow equal access to that equipment. If that equal access went away, they could move the DSL equipment further from the CO to smaller unmanned stations and extend the range of DSL services to areas where coverage isn't currently provided.
While it might push some competition out (what competition is there anyway?) bringing broadband to outlying communities would be a plus...
Just my $.02
I have a feeling that C# will be adopted by Microsoft's technology partners, but why would any firm that has spent time and money moving away from Microsoft products go running back because of a new product offering? Its not the products we're trying to get rid of, its the company.
I reply to the sending address with a spoofed email from the mailer daemon account (daemon@somedomain.com) and include a legitimate looking "undeliverable" message in the body. Most spammers are too dumb to realize that the message is spoofed and they'll remove you from their list to avoid getting tons of bounced messages when they unleash their next wave of "marketing"
Unfortunately this doesn't work well for the type of messages that contain nothing more than a bogus email address and a website link, but I like using it as a first attempt none the less...
NPR is saying it might be a Airbus A3 - there is not as of yet confirmation from the airline that owned the plane.
As for not seeing the entire class... I think that is actually one of the nicer features of VA/J. The intent is that each method (and attribute) within a class is treated as if it were a separate file, making it easier to deal with large objects. I must admit at first I hated it (VA/J was forced upon me by my employer) and ran back to vim with syntax highlighting, but once I figured out how to navigate about VA/J, I actually began to appreciate the layout.
I would guess there are better java IDEs out there, but VA/J seems to have fairly large user base and I don't have a lot of choice in the matter, so I figured I'd give my $.02 on it.
Easy to use
Reasonably priced (~$250 for the professional version)
Supported on multiple OSes (Windows, OS/2, Linux, Aix)
Can hook into external code repositories such as Visual Source Safe or PVCS
Nice debugger
Seems to be popular amongst IT shops where technology is not their primary product.
Enterprise version is quite a bit more expensive. ($3,000 + $150/seat)
Kind of bloated (256MB of RAM and 1GB of disk required for Windows version)
A little "pokey" (reportedly written in SmallTalk...)
The layout takes a while to get used to
Enterprise Builder makes heavy use of proprietary IBM classes
Ironically one of the easiest ways to cut costs in the short term becomes very expensive in the long term. My experience seems to be consistent with that of others: The QA department is staffed with bottom of the barrel technologists who don't understand what it is they are doing and aren't paid much to do it.
Hopefully many companies (not just Apple) will learn a lesson from this little blunder. The QA process should, in many respects, be larger than the development process. Many companies have the notion that good developers alone can produce good products. IMHO, most good products have good developers and great QA folks behind them.
Linux Kernel Pillow Talk
(Linux Kernel Pillow Talk: Page1of1)
By Moshe Bar
October 29, 2001
And you thought the netherworlds of dry kernel engineering were free of politics, egos, and prima-donnas? Guess again. The events of the last four to six weeks and the e-mails flying to and from the Linux kernel mailing list show how Byzantine and complex the dynamics of decision finding, features design, and implementations can be. Go to http://www.tux.org/lkml/ to subscribe to the kernel mailing list, but be careful: This is a very high-traffic list. Subscribe only if you really want to follow every single detail of the Linux kernel, or instead read the weekly digest at Linux Kernel Cousin at http://kt.zork.net/kernel-tra ffic.
Sure, the lively debates have always existed. In the past there have been disputes about the Linux firewalling code, networking code, scheduler, installer, driver model, and many more. One recurrent theme has always been the Virtual Memory (VM) manager. Nothing determines the peculiar behavior, the feel -- even the ultimate success or failure of an operating system -- like its virtual memory design. Sometime during the development cycle leading up to the Linux 2.4.0 kernel, in other words in 2.3.xx times, Rik Van Riel (http://www.surriel.com), a Dutch kernel hacker working for Brazil-based Conectiva (one of the smaller Linux distributions), introduced a radically new VM code. It was based on what seemed to be new and advanced algorithms for efficient finding, allocation, and disposal of virtual memory pages requested by programs. Rik later introduced an interesting new kernel feature called the "OOM killer." OOM stands for Out Of Memory. The OOM killer attempts to locate a killable process when memory runs out in the system. Without such a feature the whole machine can go nuts or enter a vicious cycle of swapping out a few pages, realizing immediately after that those pages are needed, and searching again for swappable page candidates, keeping the kernel busy doing only this instead of letting user processes run.
Rik is a gifted hacker, and among other things he has been trying to improve the efficiency and speed of maintenance of those lists in the kernel responsible for managing all the virtual memory pages in the system. One of the main questions to address in every operating system VM code is: "How do you choose which page to steal next when there is a RAM shortage?"
In the 2.4.0 release, the Linux kernel scans the process page and decides which page to remove. The problem with this approach is that sometimes a lot of process tables have to be scanned to free just one page, or very few pages. Also, this approach does not guarantee that the pages stolen are only those that will not be needed again very soon. Some UNIXes introduced the notion of the working set; that is, the minimum amount required by a process to function efficiently. This solution is, however, limited to per-process pages only and does not consider other kinds of pages, such as filesystem caching. Stealing from these pages might in some cases even prove counter-productive. Very often in VM theory, a solution to one problem can worsen another; that's why kernel programming is difficult.
Rik van Riel and I have variously discussed another approach, called "reverse mapping," which implements a reverse-lookup between the page and process table. Once you have reverse-mapped pages, the VM can simply scan the pages for the ones to be freed. Naturally, some extra fields need to be added to the appropriate control tables to allow this reverse mapping. My own implementation has an overhead of 14 bytes and is therefore certainly a lesser solution than Rik's -- his overhead is just 8 bytes.
Other extremely talented kernel hackers such as Marcelo Tosati and Ben LaHaise have made other important contributions to the Linux VM.
However, even though all these intelligent people tried hard to make the Linux VM fast, efficient, and powerful, user reports since the 2.4.0 release indicated poor Linux kernel performance and erratic and unstable behaviors. Up to kernel 2.4.7, for instance, on machines with small memory footprints (less than 40-MB RAM), sudden swap storms could erupt which would virtually freeze the system while it inexplicably started swapping pages in out and like crazy. In some cases, the aforementioned OOM Killer would choose the wrong process to kill; I have seen the all-important init process killed erroneously. Many fringe kernel projects, like my own Mosix project or others such as Win4Lin, suffered because users accused these projects of unstable operations, assuming that a released kernel like 2.4.0 must be free of such nasty bugs. Even though the kernel had gradually evolved from 2.4.0 to 2.4.9, it was evident that the VM design was more of a liability than an advantage.
Linus himself said in a recent kernel list mailing that he wasn't happy yet with the VM. These problems were enough for many Linux shops to resist the migration to the 2.4 kernels and instead continue using the 2.2.19 kind of kernels. Obviously, compared to 2.4., the 2.2. series has many shortcomings -- like no zero-copy networking, the division of page cache and buffer-cache in filesystem operations, big spinlocks (serializations of kernel execution paths for computers with more than one CPU) for many parts of the kernel, and so on.
A simple C program like the one below shows how kernels up to 2.4.9 had problems dealing with stress workloads on the VM system. If, after running this program, you turned the swap partition off with swapoff, your server or workstation would become totally unresponsive for up to 15 minutes.
Back in February 2001, I ran an informal and unscientific benchmark comparing FreeBSD 4.1.1 to kernel 2.4.0 (visit http://ww w.byte.com/documents/s=558/byt20010130s0010/) on exactly the same hardware and with exactly the same subsystems versions (MySQL, Sendmail, Apache, and others). The results clearly showed that, indeed, there were major problems with the efficiency and speed of the early 2.4 kernels. A New VM
Then, on September 24, with the kernel standing at version 2.4.9, everything suddenly changed. Andrea Arcangeli, an Italian kernel hacker (read my interview with him two years ago at http://ww w.byte.com/documents/s=287/byt20000229s0008/) and a very prolific contributor, decided that enough was enough. He sat down and in one of those marathon hacking bouts completely rebuilt the VM from scratch. In short succession he sent to Linus Torvalds over 150 patches to the 2.4.9 kernel, to implement a new VM engine. This is an extremely remarkable feat. A VM is a major piece of software and by nature very complex. One needs to satisfy many opposed objectives: Simultaneously efficient handling for server-type loads and interactive-type loads; ease of implementation and at the same time, optimized use of every last and small feature of the CPU. The VM must also be able to run well on Intel CPUs spanning 4 or 5 generations, as well as on AMD chips, Alphas, MIPSes, Sparcs, ARMs, and what have you. Andrea, by the way, does all his development on a Compaq AlphaServer with 2 500-MHz CPUs and 3-GB RAM.
Out of the blue, Linus accepted the new VM and incorporated it into the official Linux kernel tree.
Recently, I spent two days with Andrea giving speeches. During the two days, over many bottles of beer, we had plenty of time to discuss his new VM. I was mainly interested in how the new VM affects Mosix. Because Mosix must migrate virtual memory pages belonging to the program's address spaces between cluster nodes, it is important to correctly understand the VM and interface efficiently to it.
Specifically, Andrea took exception to the following problems in the 2.4 VM:
The new VM is much simpler and faster. Let me explain how it works.
The old 2.4 VM had a major design problem that manifested itself mainly when freeing physically dirty pages (remember dirty pages are the frames of 4-KB memory in the RAM whose contents have been modified by one of the virtual memory pages residing in it). The last owner of the page (usually the VM, except in swapoff) has to clear the dirty flag before freeing the page. When being swapped off in swapoff it may be a little more complicated -- we may need to grab the pagecache_lock to ensure nobody starts using the page while we clear it.
So, Andrea went and did the following: All physical pages are now divided into active and inactive pages. These two are further divided into dirty and clean for both active and inactive. When the active dirty pages become about 66 percent of the total number of pages, the VM starts to scan them for the oldest ones to be put into inactive dirty and then, later still, from there to the swap when memory becomes tight. This part is very central to the new VM and its simplicity is...well, simply stunning.
This elegant mechanism totally changes the behavior of the 2.4.10 kernel under heavy load and also makes for much better predictability of the system. Another very important change is that the swap is now additional to the RAM, just like in 2.2 times. All earlier 2.4 kernels (since 2.3.12) needed at least the same amount of RAM in swap and then more to give you additional virtual memory. This meant that on an 8-GB server, you needed to put aside almost a full 9-GB disk just to be able to swap, similar to some versions of Solaris or other UNIXes.
Finally, the page scanner doesn't page scan if there are theoretically no freeable pages, whereas before it did. Oh, and the OOM killer never really worked, so Andrea disabled it, as I did for all my kernels. In 2.4.12 it is enabled again; this time, however, it works much better. Try it with the above program to see it in action.
Arcangeli's VM is stable, acts predictably -- something that the old VM never really achieved -- and it makes the swap space look like it did in 2.2 days. Additionally, the design is much simpler and easier to understand. People will catch up fast with it.
However, many kernel hackers disagree. Upon the release of kernel 2.4.10, a virulent and sometimes aggressive debate flamed up, with many people trying to show why one of the two was a good VM and the other not. Some comments got a bit out of control, and only in the last two weeks or so has some calm been restored.
However, one nasty side effect stays. Alan Cox, the number two man after Linus Torvalds, does not yet like the new VM and in his own kernel tree (called the "ac tree") he still continues to use and patch the old VM. As a consequence, users and system administrators now find themselves facing two very different kernel trees to choose from: the official Linux tree and the Alan Cox tree. Quite often, latest patches to drivers and new features are only in Alan Cox's tree. Those who want to go with the official Linux source code may find themselves unable to apply the patches due to the different VM code all over. It is acceptable for the two trees to be different for a few days on such important subsystems like VM, but it is not acceptable to have them different for months and across many kernel versions.
Nobody has yet dared to speak of a Linux source fork, but this is dangerously close to one.
It became obvious that the VM up to 2.4.10 was a design liability. You can try to fix something that was designed badly, but it will never become a beauty. I think Linus' decision to scrap the old VM and go with the Arcangeli VM was courageous and right. Having a functioning and stable Linux box should not be deferred to 2.5 when we can do it already with 2.4. Kernel Preemption
But apart from the VM issues, there are other lively debates in the kernel community. There was an interesting interview at h ttp://kerneltrap.com/article.php?sid=328&mode=thre ad&order=0 with
Robert Love, who is leading one of two projects trying to make the
Linux kernel fully preemptible. Making the kernel preemptible means
making it possible to interrupt whatever the kernel is doing (say,
executing a system call) to process some other outstanding task and
then return to its original task. Linux, as a multiprocessing OS,
obviously always did that for user-land processes. However, many, just
like Robert Love, feel that the fact that Linux up to now would not
let itself be interrupted contributed to poor latency. Latency
describes how quickly you can expect a response from your kernel when
you actually need something from it. Note that Linux is not designed
as a real-time OS (though there is at least one Linux real-time
implementation somewhere), and therefore does not explicitly guarantee
latency. User-land programs must be aware of this as, especially with
kernel preemption, latencies can be very unpredictable.
Theoretically, an OS will answer faster if it can be interrupted. What does suffer from kernel preemption is the global throughput. If you have a task that gets n seconds within the kernel to complete (let's say executing a given system call takes 0.005 seconds), then all the interruptions add some overhead to switch from one kernel task to another. So, finishing the execution of that system call (in our example) will finally require n+op where p is the frequency of switching and o the static overhead for one switching operation. Notice that kernel context switching does not invalidate the CPU cache, and is therefore not as expensive as process switching. However, kernel preemption will surely lead to a higher rate of switching from kernel space to user space, because upon preemption the scheduler might decide to give higher priority to a user process.
In other words, kernel preemption does decrease latency but slows down overall throughput. It's the math: nothing to be done against it.
Furthermore, in his interview, Robert Love heavily criticized Linus Torvalds for adopting Andrea Arcangeli's new VM in 2.4.10 and dropping the old van Riel VM.
Well, I did try the patch with kernel 2.4.12 and with pre13. While accurate measurement (which Robert Love provides with the preemption kernel patches) does indeed report an improvement in latency, for the life of me I have not noticed it on an empirical basis.
I really do appreciate Love's work, but I do not fully agree with some of his comments in the interview. First, as Linus himself said, if latency sucks in the kernel then we should check why it sucks, with or without preemptive scheduling. If the latency is bad in the stock kernel, then it should be fixed anyway.
The preemptive kernel 2.4.12 worked fine on my laptops and on my SGI 550 workstation where I do interactive work. The MP3 player very rarely skipped beats when doing heavy background work such as kernel compiling or opening large files in the editor. But for my servers and clusters, the decrease in performance and the unpredictability of latency is a problem. Also, some important patches will not apply to a Love-patched kernel. Mosix, the clustering kernel extension, does not patch correctly, and neither do some versions of the LIDS intrusion detection system.
It is up to each individual user to decide whether or not to use the patch, but is important to understand the implications of using it. Linux and FreeBSD Revisited
Upon returning home the other week after meeting with Andrea, I went to my lab and searched for the disk images of the server comparison I ran back in January of this year (of FreeBSD 4.1.1 versus Linux 2.4.0). I took the Compaq ML500 server I have been reviewing (2x 1-GHz CPUs, 2-GB RAM) and upgraded both the FreeBSD disk image to 4.4-Stable and the Linux version to 2.4.12. Then, I changed the memory down to 192-MB RAM so as to stress the VM system more. I also upgraded to the latest stable versions of Sendmail (8.12.1) and MySQL (version 3.23.42). Finally, I compiled everything with the latest version of gcc, 3.0.2, and tuned the two instances to the best of my knowledge (softupdates and increased maxusers for FreeBSD, and untouched default values for Linux).
The results were very interesting indeed. Since this benchmark is too much to be handled in this article, Byte.com will post it here soon for you to read.
The story of this article is that the 2.4 kernel has finally grown up with the 2.4.10 release. Not many users outside the relatively small kernel community realize that. Now you know about it, too. Spread the good news and immediately install 2.4.12 on your busy server. The server will thank you for it.
Moshe Bar is a systems administrator and OS researcher who started learning UNIX on a PDP-11 with AT&T UNIX Release 6, back in 1981. Moshe has a M.Sc and a Ph.D. in computer science and writes UNIX-related books.
For more of Moshe's columns, visit the Serving With LinuxIndex Page . Page1of1
Better yet, how would it be enforced since there is already so many strong algorithms out there? I can see it now...
AP NEWS...
Building off the success of past handgun buyback programs, the new FBI announced today their latest effort in the war on crime, "Cash for Crypto", where computer users can turn in dangerous cryptographic software for $100 cash, no questions asked. Contact your local spook for details.
Suppose the lights turn red when downloading p0rn?
"...Roxanne! You don't have to put on the red light. Those days are over. You don't have to sell your body to the night..."
I'd rather be hourly!!!
I'm a salaried developer and was required to begin on-call support after taking the job (it wasn't part of the original job)
I'm not sure how it is for other salaried folks out there, but it didn't make any difference in my salary, title or flexibility in my schedule.
If it plays minesweeper, I'll be happy.
>You must not have looked too hard:
>http://www.sun.com/desktop/sunblade100/
That's like geek porn.
Hey everyboody! Check out the processing power on this hot little package!!!
Right now there is some poor college student out there thinking "I could probably sell my roommate and have one of those sunblades instead!"
drool....
Applying my M$-esque buisness plan, I've determined the way to gain infinite wealth is as follows...
Lets charge people over and over for something that:
(a) they already own
(b) they could have for free
(c) isn't worth half of what we're charging.
Good point, but how many MP3 whores really use SCSI anything? When you can get a 60GB IDE drive for under $200 vs. more than $400 for the same capacity in SCSI the choice is fairly clear. Especially for someone on a limited income (which clearly MP3 whores are, or they'd just buy the damn CD!)
Besides a faster drive still only masks the real problem...
...Windows
Has anyone ever tried to move large amounts of data (say, a couple MP3s at 5MB each) from a windows share using anything less than a high-speed LAN? Unlike FTP, SMB is far from speedy and is painfully slow even on a LAN (especially considering the alternatives.) This might work in limited applications, but for the most part I'm thinking the speed would be unbearable no matter how much bandwidth you have at your disposal. Scale it up to a couple hundred users and it'll be worthless.
1) War on Drugs
Bush: I've been in a war and done drugs. Personally I think war is bad, so we should just stop doing it.
Gore: I personally drove 60 elderly people in a bus to Canada to help them get their prescription drugs. I think we need to roll our tanks into Canada and take all their drugs.
2) Minority Religions...
Bush: I think as long as law abiding Americans believe in God and Jesus Christ our savior that they should be protected from persecution by the government.
Gore: I have no problems with Minorities or their religion. As a matter of fact I was just having coffee with some of my Chinese friends not that long ago where we were discussing God. They seemed a bit unclear about Jesus' role in things, but I'm sure they were just pulling my leg. Everyone believes in Jesus, right Joe? Tipper and I also proud to have a number of minority acquaintances. Our maid, our chauffer and our nanny...
3) Why give a tax cut?
Bush: I have some friends... Lets call them "major campaign contributors" for lack of a better word. They pay an astonishing $500,000 a year in taxes. Don't you think we should give these poor folks back some of that hard earned money?
Gore: I favor a tax cut. We should cut taxes but only for the poor. The wealthy people in this world can afford taxes so I'm in favor of a 50% tax cut for those people that are paying less than $200 in taxes annually.
4) electoral reform
Bush: I fully support the death penalty. If there is a problem with the electoral system, I say hire an electrician.
Gore: I say down with the third party - the third party is merely pulling away attention from the primary candidates (Nader supporters: Wake up, he doesn't stand a snowball's chance in hell. Vote for me!)
5)How Do You Feel About Intellectual Property?
Bush: Uh.... Well, I try to leave all my property dealings to the my real-estate agent. You might want to check with her.
Gore: Ever since I invented the Internet I've had strong opinions about this subject. Who does this Tim Berners-Lee guy think he is anyway? Companies and people should be able to lock their ideas up tighter than my lips on Clinton's ass. I mean, an idea is something that can't possibly be had by more than one person right? So clearly whoever thought of it first should retain full rights and get paid lots of money.
6) Encryption....
Bush: Its clear to me that no law abiding citizen has any need for encryption. American families should need to hide stuff from each other. We need to strengthen our families and foster brotherhood and friendship amongst all God fairing people under the watchfully eye of our savior Jesus Christ.
Gore: I don't see what the big deal is; some people want to be cremated, others want to be buried. If you want to be encrypted then so be it. Now one thing that we should address is international trade. I think it's a travesty that we're banning the export of American made strong crypts. We make some of the finest products in the world and I think we should vigorously pursue the open exchange of these products with our foreign friends who are passing on to the next world.
7) Rising Political Protests
Bush: My personal stock portfolio has seen a 153% gain in the past 5 years thanks to corporate interests. I think these folks are just sore because they didn't get a piece of the pie.
Gore: Yeah! What he said!
8) Asteroid Defenses
Bush: I'm all for military spending. Lets just build one really big missile and blast those asteroids into outer space.
Gore: Well, I'm no doctor, but I believe there are a number of discrete inexpensive treatments for asteroids that can be purchased at your local Walgreen's.
9) The Future of the Country, and of Humanity
Bush: Well this campaign really isn't about young people. However to address the aging population: I'll help you get your prescription drugs so your remaining years can be nothing but a pain free drug induced haze.
Gore: I must say that I am very concerned about the future of this country for all elderly people and undecided single female voters. I will promise anything you want to hear in order to get your vote back from that bastard Nader!
If you'll recall M$ had claimed at one point in time that Win98 would likely be the last "home" OS and that their home OS (Win9x) and business OS (WinNT) would converge with the release of Win2k (ha ha, yeah right!) Windows ME is just another step towards that goal.
Even though ZDnet doesn't carry the most accurate, non-biased reviews, they do have a review of Windows ME that offers a bit more insight into the architecture, how it differs from Win98 and Win2k(http://www.zdnet.com/pcmag/stories/pipreview s/0,9836,176419,00.html)
What I've heard from some of my co-workers that are on the MS Beta program: "Windows ME is essentially Win2k pro with the 98 kernel (for legacy device support) - it isn't a beefed up version of 98, its a stripped down version of Win2k." Since WinNT3.51 there hasn't been drop to dos type functionality, so it should be no surprise that its absent from ME.
So my roommate and I were mulling this over and best we can tell they have a bunch of ugly looking JScript to create a fairly complex (obscure) encryption scheme. When you start to look at it a little closer it apears to be nothing more than a XOR of the encrypted winning URL(s) with an encryption key. The key is generated using the 16 character login, 4 character password and a little math...
They do kind of throw us a bone however - the first 7 characters of the plain text are know to be 'http://' they check for this in the JScript. You could also be bold and guess that the next 15 characters are www.kipling.com That leaves 44 (web-address leagal) characters to brute force search.
Even though we are only searching web legal characters (about 101?) this is still a ugly problem to brute force. But if anyone has a spare supercomputer laying around you could definatly piss off some folks at Kippling by cracking this puppy and posting the winning URL for a true test of the slashdot effect. >:)