I never liked the way they had such an adversarial attitude toward the students.
I managed to avoid having Dr Rannie for assembler. However, he did sub for one day in my operating systems class. It was then that I understood why so many people spoke poorly of him.
He's talking about the mainframe equivalent of interrupt vectors, and using some assembly code to demonstrate how the registers are saved, etc.... I'm looking at this code and thinking, "That won't work!". So I raised my hand and asked him, "Your last instruction saved all the registers, three of which you've already overwritten?" His eyes lit up - he deliberately made a mistake to see if anyone would catch it. I got it. I got the feeling that the rest of the class didn't - they could have cared less about assembler. And that was what I think Dr Rannie hated the most. I think he was passionate about assembler; I think he was tired of dealing with ignorant students who "just wanted to pass the class..." Though I didn't have him for assembler, I get the feeling that he would not have given me much trouble, because I actually chose NIU because it taught assembler.
And 50% is a routine failure rate for that course, regardless of who teaches it.
My objection is not so much with copyright per se, but rather with the notion that a public broadcast can somehow be owned by a private entity. The airwaves are collectively owned by the public, not the record companies. As such, it is wholly compatible within copyright to require broadcast content become public domain from the perspective of redistribution without profit. (assuming, of course, that the broadcast occurs with copyright holder's permission). While I don't believe that others should be able to sell a broadcast for profit without the copyright holder's permission, I do think it is reasonable not to restrict the dissemination of content that has already been publicly broadcast by action of the copyright holder.
As much as I'd be inclined to agree with you, I'd like to posit that broadcasting a work (with the copyright holder's permission, of course) implicitly places that work in the public domain. After all, the action of broadcasting eliminates the physical possibility of the copyright holder controlling access to their work.
I know that copyright law isn't currently interpreted that way, but it should be. It just so happens that growing up, I knew families too poor to buy records and tapes. Instead, they'd tape the radio broadcasts in the afternoons and edit out the DJ's and songs they didn't like. After all, why wouldn't they? - they already paid for the radio...
There's a considerable difference in implied permission between a live music performance and a broadcast of that performance. The former is explicitly restricted to those who paid for the performance; the latter is for anyone who happens to tune in.
While corporations may claim to own the broadcasts, the EM radiation is crossing my personal property - and this without my permission. As the broadcast was unsolicited, I've signed no contracts, nor made any agreements with the radio station or the artist. I have no obligation to respect the wishes of either the artist or the radio station, because both chose to make their work available to anyone who tuned in; they instituted no means of restricting dissemination to those who had agreed to a particular contract, either written or implied.
Artists do get paid for every play on radio. Radio stations get paid for every commercial aired. So does an individual deprive an artist of revenue by recording from the radio? Absolutely not - the artist was paid before the record button was even pressed. And the same goes for those who tape television sitcoms or movies - the actors are paid by the network, which is paid by advertisers. The viewers are merely there...
As much as radio tv stations would like to restrict content even after broadcasting it, they have no moral right to do so. They have already received compensation for their efforts - the artist from the radio station, the radio station from the advertisers. If anything, broadcasting implies that the receiver is free to enjoy the content as they see fit. If this is not amenable to tv and radio stations, they always have the option of going to a pay-for-play format in which their content is distributed only to the paying consumers (i.e. cable). But most broadcasters recognize that their content isn't worth a monthly fee, and so they try to mandate access control via legislation.
Why is it that the RIAA will pay a radio station $60,000 to play their songs, and then turn around and sue a 12 year old girl for effectively "rebroadcasting" their advertisement?
So, fans get sued by the RIAA for downloading the same music the RIAA paid a radio station to broadcast. How can one be piracy, but not the other? After all, why would I buy the CD if the radio plays it all the time? Doesn't it occur to the RIAA that music fans have no need to buy the CD if the radio station is always playing a particular artist's music?
I'm kind of curious as if there are any slashdotters brave enough to distribute mp3's of these "commercials" (in their entirety, of course...) and then send the RIAA and invoice for every file downloaded...
One of the key factors that has kept Mainframes secure for so long is the fact they were designed as a secure environment in the first place:
Mainframes don't have a hardware stack, in the sense that UNIX and PC machines do. So buffer-overflow vulnerabilities are ruled out from the start.
A program must enumerate all of the system resources it uses before it begins execution. While this is certainly a PITA from a developer's perspective, it means that a running process can't be hijacked into installing a root kit. A process can't read, write, or create files unless they are specified in the JCL (And how many hackers know JCL?)
Of course, mainframes were the first to have memory protection.
That's great, except for the unholy number of I/Os you would need to route all across your motherboard.
Actually, the idea was to keep the transfers specific to a particular chip. That way, the 8192 byte bus would only exist as silicon pathways internal to the memory chip. The external connections would still be the familiar 64 or 128 bit data bus and 32 bit data bus.
Yes, it would mean that moving across a chip boundary would incur a substantial overhead. But considering that most systems ship with only 1 DIMM in the first place, this isn't necessarily an issue.
One could also make it such that the memory and the processor were integrated in one package - while upgradeability would be sacrificed, the performance increase would certainly justify it.
As we approach the physical limit of CPU performance, PC's are probably going to go the route of the mainframe - where upgrading means adding additional CPU's rather than replacing the existing one. In such an architecture, it's easier to tie the processor and main memory together on the same chip because it doesn't prevent a user from upgrading their memory - it just requires that they add a processor when doing so.
Incidentally, mainframe architecture already handles IO well - as each IO processor is doing its work, the main CPU's still fetch and process instructions from main memory. Writing to one area of memory doesn't preclude another processor from reading from another area - as you mentioned in your third point.
Is that I don't have to use bloated software. I haven't upgraded to more recent distros simply because of their slowness.
RedHat got substantially slower after 7.3, in part because:
Gnome got bigger.
The "new" X server uses a bigger footprint.
The default filesystem, ext3, is notably slower than ext2.
While none of these alone were the reason, when combined they resulted in a system that felt ran much more slowly than it's predecessors. There's a night and day difference in response times between RedHat 6.0 and 9.0.
Faster bus speeds aren't going to do it when a DMA transfer from the hard drive or ethernet card can effectively stall the processor.
What is really needed is for a memory architecture which allows the memory chip itself to move the memory, rather than having everything pass through the CPU and/or memory bus.
I've thought about this for quite some time. Consider the following memory system:
The memory chip is a 8192 x 8192 x 8 array of memory cells (64MB - put four in a machine for 256MB and 32 bit data bus). Each eight-bit byte is addressed by 8192 row and column lines.
The memory chip has three 26 bit registers: source, destination, and count. It has an additional 6 bit instruction register.
The instruction register is divided into two sections: opcode, and granularity. The opcode is a two bit field which determines one of four operations:
Read to bus
Write from bus
Internal transfer
NOP
The remaining four bits of the instruction register determine the granularity. Since their are 8192 rows, and entire row, or just part of a row of memory could be moved at a time. The contents of the six bit field contains the granularity of the operation:
0 - 1 byte
1 - 2 bytes
2 - 4 bytes
3 - 8 bytes
4 - 16 bytes
...
13 - 8192 bytes.
For regular moves, the memory works as normal: it uses the address bus to locate a byte of memory, and then places that byte on the data bus....
But, when doing large moves (rep: movsb???), the CPU figures out the length and granularity and issues instructions to the memory chip: with a 8192 byte row, the memory chip could, via a loopback circuit, move 8192 bytes per clock cycle.
With the above mentioned technique, the memory throughput for moving framebuffers and other "large" buffers on a 1 MHz (read 1000 ns RAM) chip would be 8 GB/s. With even a paltry FSB of 400MHz, that's 3.2 TB/s throughput!
Building a faster computer is not so much a matter of clock speed, but rather of efficiency. While this wouldn't improve the CPU's raw performance, it would free up the CPU to actually dedicate more clock cycles to integer and floating point workloads when performing memory intensive operations.
Yes, I paid for Windows, so I do use it occasionally. After all, it is my right to. But when I use it something just doesn't feel right.
It could be that I've read the EULA. I've never read a longer, more thoroughly articulated form of "Screw you!" than Microsoft's EULA.
In light of the way their EULA is worded, I can't help but wonder if virus vulnerability was deliberately designed into their software.
I hate the fact that HELP doesn't actually tell you how to solve the problem, but only re-iterates Microsoft's philosophy that a user shouldn't be able to configure or troubleshoot their own machine. Even should I want to learn about my own hardware, Microsoft does its best to hide as much useful information from me as possible.
People sometimes ask me to fix their PC's. I'd like to help, but often times I'd have to reinstall the OS. Without them showing me their Windows license, I can't fix their crashed machine. I don't have to worry about this with Linux, but then, all of the Linux machines I've built for people have never come back to me except for hardware failure.
But I don't merely use Linux because it's _NOT MICROSOFT_. I've learned that there are some real advantages:
I don't have to worry about security when I'm online with Linux.
I don't have to spend my weekends downloading and patching an OS that will need to be patched again next month, and the month after that, and the month after that....
I don't have to worry about opening email attachments from someone I don't know. I don't have to wonder if that attached Word document is a reply from a recruiter, or the next virus incarnation.
I like having 4 desktops. I get a machine which is actually useable for development work.
Linux is much more thoroughly documented that Windows. If my hardware isn't automatically configured, the more popular "drivers" will scan the bus and tell me the settings I need to get it working. Windows requires you to guess if it can't autoconfigure your system.
I don't have the guilt of using software written by a company which takes pride in forcing others out of business.
And my last point is probably my best one. There's a certain joy in using something that someone else created for you, not for personal profit or greed, but rather, as an act of giving back to the community that has given so much to them. I've benefitted greatly from using Linux, and I really look forward to the time when I myself will be able to give back to the community that has given so much to me. Linux is almost sacred because it is free from the influence of money; it was created for the purpose of blessing the users, not exploiting them. Linux is software the way it was meant to be.
note 'maximum' of 64MB per application, but there is no reason why an app needs to use anything near that
I used to say the same thing about the 64kB limit when working in assembly. It turns out that while I had no problem fitting the program code in the 64kB limit, my users wanted to work with data which was much larger than that.
A full page scan of a magazine cover at 300 dpi true color is around 256MB. Since multimedia has been Window's selling point for the past 10 years, I imagine that unless Sun lifts the 64MB limit on app memory, Java will never be known as anything but "The Applet Language"(tm).
And yes, you can easily work with all of the machine's memory in 32 bit assembly, and even in 16 bit asm. But in 16 bit asm, you had to painstakingly calculate segment and offset addresses if your app was going to work with more than 64k of data - and a lot of programmers didn't like to do this. Because a C compiler would automatically calculate segment and offset addresses, programmers could work with more than 64k of data without having to think about segment addressing problems, and predictably, they abandoned assembler in favor of C.
4 or 5 years ago, the average PC wasn't fast enough to run Java without significant lag times. Even now, Java still feels slow compared to apps written in C++. Had they done this earlier, developers would have rejected Java completely as simply being too slow to be usable.
I believe the duty cycle is 10 to 15 Hertz. However, it seems that the ABS itself needs about 7 cycles to recover from a poor traction mishap.
Back of the napkin calc here: I once calculated that with 14 inch rims, a P235R7014 tire rotated at 1330 RPM at 60 mph.
Divide that by 60, and we've got about 22 revolutions per second.
For the sake of argument, let's suppose that ABS can operate at 22 Hz.
So here's my hypothetical rundown of a "typical" ABS algorithm:
Wheel locks - wheel sensor detects loss of wheel motion during braking.
ABS is triggered. It reduces braking power to 50%. (I assume they use a 1/2 difference algorithm - if the wheel is locked, halve the pressure, if not, increase by one half of the difference between the user's intended pressure and current pressure.) 1/22s elapses.
Wheel is back on pavement and starts to move. But it's still moving slower than the other wheels due both the braking effect and the mass of the wheel. ABS reduces braking power to 25%. 2/22s elapsed.
The errant wheel is now moving as fast as the rest of the wheels. ABS attempts to increase braking power; braking power increased to 62% (1/2 of the difference between 25% and 100%). 3/22s elapsed.
Wheels still in sync, ABS applies the half-difference again: braking is now at 81%. 4/22s elapsed.
Wheels still in sync, ABS continues to increase using half-difference algorithm. Braking at 90%. 5/22s elapsed.
Final increase to 95% before ABS disengages. 6/22s elapsed.
Okay, some things to note here: 50 + 25 + 62 + 81 + 90 + 95 = 403 / 6 = average braking power of 67% for 6 consecutive cycles.
That's not bad, considering it took little more than 1/4 of a second. However, if we reduce the modulation frequency to 10 Hz, that increases the ABS time-to-recovery from.27 to.60 seconds. Losing 1/3 of your braking power for about half the duration of a typical panic stop is nothing to be proud of.
Again, the devil is in the details. While I won't deny that some vehicles have 4 wheel independent ABS, I believe these systems are few and far between. I don't believe that ABS in concept is worthless, but the implementations leave much to be desired in terms of real-world braking performance. Something as simple as engaging ABS only when the wheel is turned or all four wheels locked would be a significant improvement over the more popular implementations.
For the sake of argument, so let's assume that neither of us has extraordinary skill modulating the brake pedal.
So, which would you rather have?
A braking system optimized for 95% of driving conditions, or
A braking system optimized for 5% of driving conditions.
ABS is optimized for those 5% of driving conditions that drivers seldom encounter. It doesn't decrease stopping distance under any circumstances. Its sole purpose is to give the driver at least some semblance of steering control in a panic stop. The theory is, that if a driver can't stop, at least they'll be able to steer around the potential accident without having to remove their foot from the brake.
Unfortunately, the circumstances under which a driver would benefit from this are few and far between. A car without antilock brakes will stop in a shorter distance regardless of whether or not the wheels lock - while it is true that locked wheels lengthen stopping distances, the difference is trivial. ABS systems are tuned to keep the wheels rolling, not to provide maximum braking power. The result is that if the ABS is triggered during a panic stop, the car actually loses stopping power.
To explain further, here's what typically happens:
(These estimates are based on my seat-of-the-pants accelerometer, YMMV)
Driver sees traffic come to a screeching halt, and applies brakes hard enough to stop before he gets to the car in front of him. He doesn't slam on the brakes, but hits them pretty hard.
The vehicle rolls over a bump or pothole. As the wheel lifts off the pavement, the brakes lock the wheel.
ABS is triggered, modulating the brake pressure.
The wheel returns to the pavement, and starts rolling again. All four tires now have optimal frictional contact, but it will take the ABS system another second or two to figure this out.
The driver sense that he's lost braking power, so he pushes the pedal down farther. The ABS system recognizes that this is typical of what drivers do during slippery conditions, so it remains engaged. As the driver applies more pressure to the pedal, the ABS system bleeds off this pressure.
The vehicle, having lost about 50% of normal braking power, collides with the vehicle in front of it. After all four wheels have stopped, the ABS system determines that there is no longer a need to active itself and disengages.
With ABS, it's literally a case of too little, too late. It takes the typical ABS system at least.5 seconds to determine that the wheels have regained full traction. That's 45 feet of stopping distance at 60 mph. The driver in this case could have stopped had the ABS not been triggered. The problem is not with the frequency - ABS systems can modulate much faster than a human foot - but with the accuracy; when an ABS system encounters wheel lock, it reduces braking power to levels far below what a reasonably skilled driver would be able to maintain. The average driver who detects wheel lock can reduce pressure on the brakes and maintain about 70% to 80% of wheel-lockup pressure. But when ABS kicks in, braking power is typically reduced to less than 50% of wheel-locking pressure.
Now you might say, well, you're just a skilled driver. But it isn't just me; several of my friends have reported the same phenomenon, across cars of different makes - when the ABS kicks in, the pedal goes to the floor and they think their brakes have failed completely because of the drastic reduction in stopping power. Even my sister, complains that "the brakes don't work when it's wet out." She never complained about this before she drove a car with anti-lock brakes.
And this doesn't even address the situation in which the driver simply can't steer around an accident - as is typical on crowded urban expressways. I've seen multiple car pileups in which neither of two drivers could stop; the first takes the shoulder and the second, with no
What really irks me is that these chemicals aren't even needed - flame retardants are used because US companies fear getting sued if someone's monitor catches fire and burns down the building.
It appears that in their "quest for safety", or "liability shield" in corporate-speak, they've actually made their products more hazardous.
Quite frankly, I'm sick of the "We must do something" approach. This is the same thinking that led to:
Companies using a flame retardant in children's pajamas which was later found to be carcinogenic. The consumer didn't even know the fabric had been treated. But someone just knew that having flame-retardant pajamas would protect kids, in spite of the fact that the heat and toxic gases in a fire would kill them long before their clothes caught fire.
The introduction of Asian ladybugs in the Midwest. Since these eat aphids, which harm crops, it was reasoned that bringing them to the midwest would help out farmers. Turns out that the ladybugs are now a bigger nuisance than the aphids.
Mandatory "safety" features like anti-lock brakes and airbags. The former lengthens the stopping distance on dry pavement, while the latter have actually killed people. Before antilock brakes, a driver had a reasonable expectation that slamming on the brakes would stop the car quickly. But drivers are now routinely reporting brakes that "didn't work" after an accident; because triggering the ABS causes such a wide variance in actual stopping distance, a driver can no longer reliably estimate stopping distance. It used to be that you could put a child seat in the front seat of a vehicle, but thanks to airbags, a mother must put the child in the back, where she must turn around and take her eyes off the road to attend to her child.
The widespread spraying of insecticides to control mosquitos. Apparently, avoiding the nuisance of mosquito bites in the present was more important than preventing cancer in the future.
The adoption of preservatives in food processing, whose cumulative effects are often unknown. Because, as we all know, it's better to systematically poison the whole population slowly than risk food spoilage.
The use of artificial sweeteners, some of which become very toxic when broken down chemically, others which cause cancer.
The biggest problem with "Safety Rush" is that it isn't safe. The inclusion of safety chemicals and features creates the situation in which consumers are collectively dumbed-down; witness, for example, the idiot who tried to trim his hedges with a lawn mower and cut off his fingers in the process. He expected the mower to have a warning that you couldn't use it for that purpose. Why did he expect that? Well, because American companies have gone out of their way to ensure that, to the maximum extent possible, the consumer can't hurt themselves with their product.
In the end, what it really comes down to is that the Safety Rush hurts more people than it helps. At best, it lulls people into a sense of complacency when working with dangerous equipment; at worst, risk to the consumer is compounded by the use of chemicals which aren't known to be safe. While fire is certainly a safety hazard, its danger is much more easily mitigated by the consumer than the risk of cancer through unknowingly being exposed to flame retardants.
And how is this news? Windows users expect to get hit by viruses; this is nothing new.
When Linux starts getting hit, then I'll take notice.
All those people who claim that Linux is ready for the desktop conveniently forget that it still doesn't support anywhere near the number of viruses that Windows does. A single release of Windows contains more virus enablement than all releases of Linux combined. When it comes down to it, Linux won't ever break into the desktop mainstream until Linus improves support for viruses.
The difference between EXT2 and EXT3 is the difference between being faster than windows and slower than windows.
Incidentally, NTFS is considerably slower than FAT for some tasks; it would seem that the journalling of both NTFS and EXT3 is to blame for their slow performance.
Wasn't this the very thing that open source was supposed to avoid?
You don't like the copy and paste works? Fine - you've got the source code, so just change the key codes and recompile.... right?
After a few frustrating hours of digging through source code, you finally find the keybindings. You change them, do a make.... and make crashes. So then you debug the make script and realize that you _ALSO_ need the source code to an obscure set of libraries. So you Google it, download the source, and it ALSO won't compile, because you've got the wrong compiler version.
So you figure, what the heck, it's time to upgrade gcc anyway. You download the sources, compile it, only to find that you also need to download the sources for the shared libraries as well. Tomorrow, you'll resume.
Well the weekend is coming up, and you've finally got the compiler and all its dependent sources together, and you start the compile. It actually compiles and installs just fine... And then you try to compile those obscure libraries and the compiler crashes. Turns out there's a kernel bug which means the new version of the compiler won't work with older kernels. You think, well heck, I'll just upgrade my kernel, and you ftp the sources.
So you configure your kernel and then type 'make clean; make dep; make install' and kick off the process; it dies - once again, your compiler segfaults. So now you've got an older kernel with no way to compile the new one...
So next weekend you decide that you're just going back to the old compiler. You rpm -i the compiler, and start the kernel compile process again... but the new kernel won't compile with the older compiler, and the newer compiler won't run on an older kernel....
You take a walk. It's nice to see the sunshine, and feel the breeze for a change.
It's tuesday and you've figured out that you can apply a few patches to your current compiler source, compile that, and then you'll be able to compile the most recent version of the compiler. So you do that. After you've built your intermediate version, you install it, build your kernel, and then recompile the newest compiler sources. After a reboot, you're able to successfully compile those obscure shared libraries, and rebuild your application.
Then you fire up your modified ctrl-c, ctrl-v enhanced software....
It segfaults. For no apparent reason.
So you Google the newsgroups, and lo and behold, someone else is having the same problem! But they don't know what the problem is.
Next week, your newsgroup buddy has found the problem. It turns out that a change in the way gcc handles memory allocation causes your obscure libraries to crash when compiled with the newer versions. They recommend using an older version of the compiler to build the software.
So you go back to the intermediate version, recompile, and finally, everything works great. For a few days, you've been enjoying the benefits of ctrl-c ctrl-v copy and paste. Life is good.
And then, you notice that KDE starts crashing at random for some unknown reason...
So of course they're going to insist on email disclaimers.
These have as much authority as someone posting a sign which says, "By reading this, you agree to pay me ten dollars."
It is similar to the EULA's in software. Since the user already owns the license by the time they click the "I agree" button, the vendor cannot simply impose arbitrary terms with any legal force.
Now, a IANAL, and one might tell you differently. But consider this: if EULA's were legally binding, a customer that altered the EULA text to state, "Vendor agrees that user now owns Vendor..." could legally take possession of Microsoft with a click of the mouse!
Since an agreement implies that both parties agree to something, a EULA cannot be an agreement unless both sides are free to change it.
And exactly how obvious is this? - to a non-technical user?
And we're telling people that Linux isn't ready for the desktop?
Those who point to the difficulties of OS installation as evidence that Linux isn't ready for the desktop would do well to remind themselves of the number of times that Windows users have had to reinstall their operating system because the user:
Couldn't figure out how to fix a configuration setting, or:
Didn't know enough about the system to realize that a reinstall wasn't necessary, or:
Reinstalled because this is Microsoft's "standard" answer for every technical glitch, or:
Did not know any other way to correct the problem because the Microsoft Help didn't explain how the system worked so they could do their own troubleshooting.
It's one of those "fuzzy" regulations used to bust people like Branch Davidians and such.
Owning a pair of NVG's is not actionable, but owning several pairs is. It is similar to firearms - you can call the FBI and ask them how many firearms you can buy, and they won't give you a concrete answer. But if the FBI thinks you have "too many" firearms, they can bust down your doors Waco-style and haul you off to court. "Stockpiling weapons" is technically illegal, but the law is so poorly defined that it can include even legitimate activities.
Kind of like "terrorist activities". You hear of people getting arrested for "terrorism" and "terrorist activities", but you never hear the details of what, exactly, they were doing that was illegal. "Terrorism" is technically not an offense - murder, conspiracy, etc... are. But by using the blanket misnomer "terrorist activities", the Feds can bust someone they think is guilty for possessing ordinary objects (Like your average garage doesn't have wire cutters and batteries) or doing ordinary things when associated with "terrorist suspects".
It doesn't have to be a specific statute to be enforced, as there are so many which are so broad that they could be construed to represent whatever the defendant happened to be doing at the time. Incidentally, a literal interpretation of the PATRIOT act makes double-parking a terrorist offense. The law defines terrorism as something which disrupts the public order and involves a flammable substance. Since your double-parking your car disrupts the public order, and your car contains gasoline (a flammable substance), anyone who double parks a car could literally be tried as a terrorist.
That possession of Night Vision Goggles is a crime?
It's seldom prosecuted, but it is in fact illegal - they are considered "armament" in much the same way that bulletproof vests, helmets, and "gas" masks are. It is illegal to stockpile weapons, and NVG's are considered "weapons" by the State Department. As I imagine that a large theater probably has more than a few pairs, they'd probably qualify as a "stockpiler" under the law.
Kind of ironic, isn't it - in order to prevent a civil offense, movie theaters are inadvertently committing a federal crime....
Also, more interesting - should a court find that a theater overcharged its customers, the presence of "weapons" - as defined by armed robbery laws - would make them guilty of armed robbery as opposed to a simple theft. I wonder if anyone has thought about the implications of this...
And yes, there are states *cough* Arizona *cough* with attorneys general that do enforce the law, word-for-word. (A recent father was convicted of murder and sentenced to the mandatory minimum jail sentence for a traffic accident which killed his child. A law was recently passed which automatically makes the perpetrator guilty of murder if anyone is killed in the commission of a crime, even if they themselves didn't directly cause the death - his offense was running a red light. In another case, a startled homeowner shot his own son during a burglary attempt and the burglar was charged with murder - even though neither had any intention of killing anyone.)
although I suspect Brown simply didn't know enough to be able to differentiate between the two.
So why does it matter?
Why should we even bother reading such FUD if we already know the author doesn't posses the capability to make a reasoned argument? And whose fault is it if we get mad at what they say?
It is pieces like this which say far more about Microsoft than they do about Linux. This is as bad as people criticizing Microsoft carte-blanche with no rationale whatsoever.
I suppose these articles are useful as flame-fodder, but they do very little toward actually providing enlightment concerning the issues facing both Windows and Linux.
Slashdot Mirror
I never liked the way they had such an adversarial attitude toward the students.
I managed to avoid having Dr Rannie for assembler. However, he did sub for one day in my operating systems class. It was then that I understood why so many people spoke poorly of him.
He's talking about the mainframe equivalent of interrupt vectors, and using some assembly code to demonstrate how the registers are saved, etc.... I'm looking at this code and thinking, "That won't work!". So I raised my hand and asked him, "Your last instruction saved all the registers, three of which you've already overwritten?" His eyes lit up - he deliberately made a mistake to see if anyone would catch it. I got it. I got the feeling that the rest of the class didn't - they could have cared less about assembler. And that was what I think Dr Rannie hated the most. I think he was passionate about assembler; I think he was tired of dealing with ignorant students who "just wanted to pass the class..." Though I didn't have him for assembler, I get the feeling that he would not have given me much trouble, because I actually chose NIU because it taught assembler.
And 50% is a routine failure rate for that course, regardless of who teaches it.
Assembler is used as a weed-out course. This course humbles a lot of hackers....
My objection is not so much with copyright per se, but rather with the notion that a public broadcast can somehow be owned by a private entity. The airwaves are collectively owned by the public, not the record companies. As such, it is wholly compatible within copyright to require broadcast content become public domain from the perspective of redistribution without profit. (assuming, of course, that the broadcast occurs with copyright holder's permission). While I don't believe that others should be able to sell a broadcast for profit without the copyright holder's permission, I do think it is reasonable not to restrict the dissemination of content that has already been publicly broadcast by action of the copyright holder.
As much as I'd be inclined to agree with you, I'd like to posit that broadcasting a work (with the copyright holder's permission, of course) implicitly places that work in the public domain. After all, the action of broadcasting eliminates the physical possibility of the copyright holder controlling access to their work.
I know that copyright law isn't currently interpreted that way, but it should be. It just so happens that growing up, I knew families too poor to buy records and tapes. Instead, they'd tape the radio broadcasts in the afternoons and edit out the DJ's and songs they didn't like. After all, why wouldn't they? - they already paid for the radio...
There's a considerable difference in implied permission between a live music performance and a broadcast of that performance. The former is explicitly restricted to those who paid for the performance; the latter is for anyone who happens to tune in.
While corporations may claim to own the broadcasts, the EM radiation is crossing my personal property - and this without my permission. As the broadcast was unsolicited, I've signed no contracts, nor made any agreements with the radio station or the artist. I have no obligation to respect the wishes of either the artist or the radio station, because both chose to make their work available to anyone who tuned in; they instituted no means of restricting dissemination to those who had agreed to a particular contract, either written or implied.
Artists do get paid for every play on radio. Radio stations get paid for every commercial aired. So does an individual deprive an artist of revenue by recording from the radio? Absolutely not - the artist was paid before the record button was even pressed. And the same goes for those who tape television sitcoms or movies - the actors are paid by the network, which is paid by advertisers. The viewers are merely there...
As much as radio tv stations would like to restrict content even after broadcasting it, they have no moral right to do so. They have already received compensation for their efforts - the artist from the radio station, the radio station from the advertisers. If anything, broadcasting implies that the receiver is free to enjoy the content as they see fit. If this is not amenable to tv and radio stations, they always have the option of going to a pay-for-play format in which their content is distributed only to the paying consumers (i.e. cable). But most broadcasters recognize that their content isn't worth a monthly fee, and so they try to mandate access control via legislation.
Why is it that the RIAA will pay a radio station $60,000 to play their songs, and then turn around and sue a 12 year old girl for effectively "rebroadcasting" their advertisement?
So, fans get sued by the RIAA for downloading the same music the RIAA paid a radio station to broadcast. How can one be piracy, but not the other? After all, why would I buy the CD if the radio plays it all the time? Doesn't it occur to the RIAA that music fans have no need to buy the CD if the radio station is always playing a particular artist's music?
I'm kind of curious as if there are any slashdotters brave enough to distribute mp3's of these "commercials" (in their entirety, of course...) and then send the RIAA and invoice for every file downloaded...
One of the key factors that has kept Mainframes secure for so long is the fact they were designed as a secure environment in the first place:
Actually, the idea was to keep the transfers specific to a particular chip. That way, the 8192 byte bus would only exist as silicon pathways internal to the memory chip. The external connections would still be the familiar 64 or 128 bit data bus and 32 bit data bus.
Yes, it would mean that moving across a chip boundary would incur a substantial overhead. But considering that most systems ship with only 1 DIMM in the first place, this isn't necessarily an issue.
One could also make it such that the memory and the processor were integrated in one package - while upgradeability would be sacrificed, the performance increase would certainly justify it.
As we approach the physical limit of CPU performance, PC's are probably going to go the route of the mainframe - where upgrading means adding additional CPU's rather than replacing the existing one. In such an architecture, it's easier to tie the processor and main memory together on the same chip because it doesn't prevent a user from upgrading their memory - it just requires that they add a processor when doing so.
Incidentally, mainframe architecture already handles IO well - as each IO processor is doing its work, the main CPU's still fetch and process instructions from main memory. Writing to one area of memory doesn't preclude another processor from reading from another area - as you mentioned in your third point.
Is that I don't have to use bloated software. I haven't upgraded to more recent distros simply because of their slowness.
RedHat got substantially slower after 7.3, in part because:
While none of these alone were the reason, when combined they resulted in a system that felt ran much more slowly than it's predecessors. There's a night and day difference in response times between RedHat 6.0 and 9.0.
Is the PC's failing memory architecture.
Faster bus speeds aren't going to do it when a DMA transfer from the hard drive or ethernet card can effectively stall the processor.
What is really needed is for a memory architecture which allows the memory chip itself to move the memory, rather than having everything pass through the CPU and/or memory bus.
I've thought about this for quite some time. Consider the following memory system:
Building a faster computer is not so much a matter of clock speed, but rather of efficiency. While this wouldn't improve the CPU's raw performance, it would free up the CPU to actually dedicate more clock cycles to integer and floating point workloads when performing memory intensive operations.
There will be a need for sysadmins...
Many things...
Yes, I paid for Windows, so I do use it occasionally. After all, it is my right to. But when I use it something just doesn't feel right.
But I don't merely use Linux because it's _NOT MICROSOFT_. I've learned that there are some real advantages:
And my last point is probably my best one. There's a certain joy in using something that someone else created for you, not for personal profit or greed, but rather, as an act of giving back to the community that has given so much to them. I've benefitted greatly from using Linux, and I really look forward to the time when I myself will be able to give back to the community that has given so much to me. Linux is almost sacred because it is free from the influence of money; it was created for the purpose of blessing the users, not exploiting them. Linux is software the way it was meant to be.
note 'maximum' of 64MB per application, but there is no reason why an app needs to use anything near that
I used to say the same thing about the 64kB limit when working in assembly. It turns out that while I had no problem fitting the program code in the 64kB limit, my users wanted to work with data which was much larger than that.
A full page scan of a magazine cover at 300 dpi true color is around 256MB. Since multimedia has been Window's selling point for the past 10 years, I imagine that unless Sun lifts the 64MB limit on app memory, Java will never be known as anything but "The Applet Language"(tm).
And yes, you can easily work with all of the machine's memory in 32 bit assembly, and even in 16 bit asm. But in 16 bit asm, you had to painstakingly calculate segment and offset addresses if your app was going to work with more than 64k of data - and a lot of programmers didn't like to do this. Because a C compiler would automatically calculate segment and offset addresses, programmers could work with more than 64k of data without having to think about segment addressing problems, and predictably, they abandoned assembler in favor of C.
4 or 5 years ago, the average PC wasn't fast enough to run Java without significant lag times. Even now, Java still feels slow compared to apps written in C++. Had they done this earlier, developers would have rejected Java completely as simply being too slow to be usable.
I believe the duty cycle is 10 to 15 Hertz. However, it seems that the ABS itself needs about 7 cycles to recover from a poor traction mishap.
Back of the napkin calc here: I once calculated that with 14 inch rims, a P235R7014 tire rotated at 1330 RPM at 60 mph.
Divide that by 60, and we've got about 22 revolutions per second.
For the sake of argument, let's suppose that ABS can operate at 22 Hz.
So here's my hypothetical rundown of a "typical" ABS algorithm:
Okay, some things to note here: 50 + 25 + 62 + 81 + 90 + 95 = 403 / 6 = average braking power of 67% for 6 consecutive cycles.
That's not bad, considering it took little more than 1/4 of a second. However, if we reduce the modulation frequency to 10 Hz, that increases the ABS time-to-recovery from .27 to .60 seconds. Losing 1/3 of your braking power for about half the duration of a typical panic stop is nothing to be proud of.
Again, the devil is in the details. While I won't deny that some vehicles have 4 wheel independent ABS, I believe these systems are few and far between. I don't believe that ABS in concept is worthless, but the implementations leave much to be desired in terms of real-world braking performance. Something as simple as engaging ABS only when the wheel is turned or all four wheels locked would be a significant improvement over the more popular implementations.
Someone who browsed LinuxToday was actually going to go out and buy a Microsoft product?!
If LT is gets hits on a click-through basis, I say we /. them so that at least Microsoft will be spending some money to support Linux.
I mean, what's the harm in taking money from Microsoft? Wasn't that what Linux advocacy was all about in the first place?
For the sake of argument, so let's assume that neither of us has extraordinary skill modulating the brake pedal.
So, which would you rather have?
ABS is optimized for those 5% of driving conditions that drivers seldom encounter. It doesn't decrease stopping distance under any circumstances. Its sole purpose is to give the driver at least some semblance of steering control in a panic stop. The theory is, that if a driver can't stop, at least they'll be able to steer around the potential accident without having to remove their foot from the brake.
Unfortunately, the circumstances under which a driver would benefit from this are few and far between. A car without antilock brakes will stop in a shorter distance regardless of whether or not the wheels lock - while it is true that locked wheels lengthen stopping distances, the difference is trivial. ABS systems are tuned to keep the wheels rolling, not to provide maximum braking power. The result is that if the ABS is triggered during a panic stop, the car actually loses stopping power.
To explain further, here's what typically happens: (These estimates are based on my seat-of-the-pants accelerometer, YMMV)
With ABS, it's literally a case of too little, too late. It takes the typical ABS system at least .5 seconds to determine that the wheels have regained full traction. That's 45 feet of stopping distance at 60 mph. The driver in this case could have stopped had the ABS not been triggered. The problem is not with the frequency - ABS systems can modulate much faster than a human foot - but with the accuracy; when an ABS system encounters wheel lock, it reduces braking power to levels far below what a reasonably skilled driver would be able to maintain. The average driver who detects wheel lock can reduce pressure on the brakes and maintain about 70% to 80% of wheel-lockup pressure. But when ABS kicks in, braking power is typically reduced to less than 50% of wheel-locking pressure.
Now you might say, well, you're just a skilled driver. But it isn't just me; several of my friends have reported the same phenomenon, across cars of different makes - when the ABS kicks in, the pedal goes to the floor and they think their brakes have failed completely because of the drastic reduction in stopping power. Even my sister, complains that "the brakes don't work when it's wet out." She never complained about this before she drove a car with anti-lock brakes.
And this doesn't even address the situation in which the driver simply can't steer around an accident - as is typical on crowded urban expressways. I've seen multiple car pileups in which neither of two drivers could stop; the first takes the shoulder and the second, with no
What really irks me is that these chemicals aren't even needed - flame retardants are used because US companies fear getting sued if someone's monitor catches fire and burns down the building.
It appears that in their "quest for safety", or "liability shield" in corporate-speak, they've actually made their products more hazardous.
Quite frankly, I'm sick of the "We must do something" approach. This is the same thinking that led to:
The biggest problem with "Safety Rush" is that it isn't safe. The inclusion of safety chemicals and features creates the situation in which consumers are collectively dumbed-down; witness, for example, the idiot who tried to trim his hedges with a lawn mower and cut off his fingers in the process. He expected the mower to have a warning that you couldn't use it for that purpose. Why did he expect that? Well, because American companies have gone out of their way to ensure that, to the maximum extent possible, the consumer can't hurt themselves with their product.
In the end, what it really comes down to is that the Safety Rush hurts more people than it helps. At best, it lulls people into a sense of complacency when working with dangerous equipment; at worst, risk to the consumer is compounded by the use of chemicals which aren't known to be safe. While fire is certainly a safety hazard, its danger is much more easily mitigated by the consumer than the risk of cancer through unknowingly being exposed to flame retardants.
How many of these affect Linux?
Oh, right.
And how is this news? Windows users expect to get hit by viruses; this is nothing new.
When Linux starts getting hit, then I'll take notice.
All those people who claim that Linux is ready for the desktop conveniently forget that it still doesn't support anywhere near the number of viruses that Windows does. A single release of Windows contains more virus enablement than all releases of Linux combined. When it comes down to it, Linux won't ever break into the desktop mainstream until Linus improves support for viruses.
The reason:
EXT3
The difference between EXT2 and EXT3 is the difference between being faster than windows and slower than windows.
Incidentally, NTFS is considerably slower than FAT for some tasks; it would seem that the journalling of both NTFS and EXT3 is to blame for their slow performance.
Wasn't this the very thing that open source was supposed to avoid?
You don't like the copy and paste works? Fine - you've got the source code, so just change the key codes and recompile.... right?
After a few frustrating hours of digging through source code, you finally find the keybindings. You change them, do a make.... and make crashes. So then you debug the make script and realize that you _ALSO_ need the source code to an obscure set of libraries. So you Google it, download the source, and it ALSO won't compile, because you've got the wrong compiler version.
So you figure, what the heck, it's time to upgrade gcc anyway. You download the sources, compile it, only to find that you also need to download the sources for the shared libraries as well. Tomorrow, you'll resume.
Well the weekend is coming up, and you've finally got the compiler and all its dependent sources together, and you start the compile. It actually compiles and installs just fine... And then you try to compile those obscure libraries and the compiler crashes. Turns out there's a kernel bug which means the new version of the compiler won't work with older kernels. You think, well heck, I'll just upgrade my kernel, and you ftp the sources.
So you configure your kernel and then type 'make clean; make dep; make install' and kick off the process; it dies - once again, your compiler segfaults. So now you've got an older kernel with no way to compile the new one...
So next weekend you decide that you're just going back to the old compiler. You rpm -i the compiler, and start the kernel compile process again... but the new kernel won't compile with the older compiler, and the newer compiler won't run on an older kernel....
You take a walk. It's nice to see the sunshine, and feel the breeze for a change.
It's tuesday and you've figured out that you can apply a few patches to your current compiler source, compile that, and then you'll be able to compile the most recent version of the compiler. So you do that. After you've built your intermediate version, you install it, build your kernel, and then recompile the newest compiler sources. After a reboot, you're able to successfully compile those obscure shared libraries, and rebuild your application.
Then you fire up your modified ctrl-c, ctrl-v enhanced software....
It segfaults. For no apparent reason.
So you Google the newsgroups, and lo and behold, someone else is having the same problem! But they don't know what the problem is.
Next week, your newsgroup buddy has found the problem. It turns out that a change in the way gcc handles memory allocation causes your obscure libraries to crash when compiled with the newer versions. They recommend using an older version of the compiler to build the software.
So you go back to the intermediate version, recompile, and finally, everything works great. For a few days, you've been enjoying the benefits of ctrl-c ctrl-v copy and paste. Life is good.
And then, you notice that KDE starts crashing at random for some unknown reason...
So of course they're going to insist on email disclaimers.
These have as much authority as someone posting a sign which says, "By reading this, you agree to pay me ten dollars."
It is similar to the EULA's in software. Since the user already owns the license by the time they click the "I agree" button, the vendor cannot simply impose arbitrary terms with any legal force.
Now, a IANAL, and one might tell you differently. But consider this: if EULA's were legally binding, a customer that altered the EULA text to state, "Vendor agrees that user now owns Vendor..." could legally take possession of Microsoft with a click of the mouse!
Since an agreement implies that both parties agree to something, a EULA cannot be an agreement unless both sides are free to change it.
And exactly how obvious is this? - to a non-technical user?
And we're telling people that Linux isn't ready for the desktop?
Those who point to the difficulties of OS installation as evidence that Linux isn't ready for the desktop would do well to remind themselves of the number of times that Windows users have had to reinstall their operating system because the user:
It's one of those "fuzzy" regulations used to bust people like Branch Davidians and such.
Owning a pair of NVG's is not actionable, but owning several pairs is. It is similar to firearms - you can call the FBI and ask them how many firearms you can buy, and they won't give you a concrete answer. But if the FBI thinks you have "too many" firearms, they can bust down your doors Waco-style and haul you off to court. "Stockpiling weapons" is technically illegal, but the law is so poorly defined that it can include even legitimate activities.
Kind of like "terrorist activities". You hear of people getting arrested for "terrorism" and "terrorist activities", but you never hear the details of what, exactly, they were doing that was illegal. "Terrorism" is technically not an offense - murder, conspiracy, etc... are. But by using the blanket misnomer "terrorist activities", the Feds can bust someone they think is guilty for possessing ordinary objects (Like your average garage doesn't have wire cutters and batteries) or doing ordinary things when associated with "terrorist suspects".
It doesn't have to be a specific statute to be enforced, as there are so many which are so broad that they could be construed to represent whatever the defendant happened to be doing at the time. Incidentally, a literal interpretation of the PATRIOT act makes double-parking a terrorist offense. The law defines terrorism as something which disrupts the public order and involves a flammable substance. Since your double-parking your car disrupts the public order, and your car contains gasoline (a flammable substance), anyone who double parks a car could literally be tried as a terrorist.
That possession of Night Vision Goggles is a crime?
It's seldom prosecuted, but it is in fact illegal - they are considered "armament" in much the same way that bulletproof vests, helmets, and "gas" masks are. It is illegal to stockpile weapons, and NVG's are considered "weapons" by the State Department. As I imagine that a large theater probably has more than a few pairs, they'd probably qualify as a "stockpiler" under the law.
Kind of ironic, isn't it - in order to prevent a civil offense, movie theaters are inadvertently committing a federal crime....
Also, more interesting - should a court find that a theater overcharged its customers, the presence of "weapons" - as defined by armed robbery laws - would make them guilty of armed robbery as opposed to a simple theft. I wonder if anyone has thought about the implications of this...
And yes, there are states *cough* Arizona *cough* with attorneys general that do enforce the law, word-for-word. (A recent father was convicted of murder and sentenced to the mandatory minimum jail sentence for a traffic accident which killed his child. A law was recently passed which automatically makes the perpetrator guilty of murder if anyone is killed in the commission of a crime, even if they themselves didn't directly cause the death - his offense was running a red light. In another case, a startled homeowner shot his own son during a burglary attempt and the burglar was charged with murder - even though neither had any intention of killing anyone.)
So why does it matter?
Why should we even bother reading such FUD if we already know the author doesn't posses the capability to make a reasoned argument? And whose fault is it if we get mad at what they say?
It is pieces like this which say far more about Microsoft than they do about Linux. This is as bad as people criticizing Microsoft carte-blanche with no rationale whatsoever.
I suppose these articles are useful as flame-fodder, but they do very little toward actually providing enlightment concerning the issues facing both Windows and Linux.