Ever notice how Katz always posts statistics and studies that "aren't published yet".
Worse yet, the myth of the "digital divide" is based on old numbers. Adam Clayton Powell III covered this last century (by either reckoning) in this article that showed how computer access was penetrating the lower socioeconomic strata.
As some have pointed out, individuals make the decision to buy a nicer car, TV set, PS2, stereo, cellphone, shoes endorsed by big jocks.... instead of computers. The slight differences in computer ownership that exist today are the result of those choices.
What we as The Community can do is encourage our employers to take the old hardware being replaced in upgrades, and donate it to inner-city schools, churches, community centers, etc... and then bring our LUGs along to do installfests, and train up some new members while we're at it.
You cannot link any proprietary code to a GPL library.
Actually, you can, provided that you don't distribute the library with the proprietary code. In order for this to work, the proprietary code must be able to do something meaningful on its own, so as to qualify as an independent work "not based on" the GPL code. What that means is a matter for lawyers, who can debate what the meaning of "is" is.
is it really worth it to start one from scratch that you know is going to be mediocre when you can just help the community to make a smaller number of really great versions?
How about this idea, then: Take an existing project like Slashcode or Scoop, and abstract it into separate code components, so that it's easy to tweak the comment moderation system, whether to allow Mere Users to moderate the message submission queue, whether to distinguish "front-page" vs. "section" or not, and presentation issues separately. Ultimately, a single engine could have a config file that allows great flexibility. Think "make config" here. One source tree, astronomical combinations.
Come on, its not a baskin robbins.
Actually, it should be. When I go to B-R, I typically have a shake made out of three scoops, each of a different flavor (giving me 4495 combinations, a few hundred of which might even taste good). I don't need to build a whole new blender or force retraining of the personnel to accomplish this. Just plug in different parameters in the existing system.
Who's going to edit the web? Is he volunteering? I think the Founding Fathers passed the First Amendment because they didn't want to sit around and adjudicate disputes over the written word.
Actually, they passed it because they thought that such "disputes" were an integral part of the process of arriving at the truth. Empowering the faction that happens to be in the majority at any given time to suppress dissidents short-circuits the process, and substitutes force for reason.
The most restrictive readings of the First Amendment say that it only applies to political speech. Perhaps this is because even those who advocate government control of speech recognize the monstrous fundamental contradiction of the regulation of speech (especially of a political nature) by a government that is supposed to be elected by the very people whose access to information is being regulated.
You can try to make the case that children, mentally handicapped people, even convicted criminals as the author of the article suggests, can't handle just any information that's thrown at them. But such controls are always extended to the population at large.
If We The People are too damn stupid to judge the information providers ourselves, then how in the fsck are We magically transformed into voters competent to elect people to judge for us all?
When my Linux server is booting, I know when something's wrong by how long the [OK] takes to appear, so even the [OK] is useful.
Well, a server operator such as yourself probably doesn't even have X loaded, or maybe even on the system at all. To most of the folks who hang here, gooey stuff is just fluff.
But if a (yes, ACs out there who disdain such) commercial distro escorts its users directly into X, and only bothers them when Something Is Seriously Wrong, and that increases the user base of Linux, it's is a Good Thing for us all. Or, we can be arrogant assholes like "Nick Burns, Your Company's Computer Guy" and let MS keep them as customers.
Microsoft learned a long time ago that 99% of their users don't understand or care about those lines scrolling by, and in fact it intimidates them.
I don't see this as an either/or situation. A boot parameter passed by LILO/whatever could enable/disable the Pretty Boot. Runlevel 5 might be your first clue, defaulting to Pretty, and lower levels assuming The Gory Details.
But even with the Eye Candy, the normal init messages would still be visible in another console, (and a prompt as to what Ctrl-Alt combination brought that one up for the distro in question--or maybe make it really easy and use Esc to switch to the boot messages) but the first time something other than "[OK]" came up, the error message could show up on the Pretty Boot screen (and the prompt might change colors).
This is not even that foreign from the SOP for *nix utilities: Most of them output nothing to the console when they did what you asked, only bothering to tell you when something went wrong. (That's why it's called stderr.) A boot process that shows that progress has been made, and only tells the user what went wrong, sounds like a reasonable setup for most people.
Authors have already received their cut of used book proceeds...when it was sold new.
If Amazon helps to develop a secondary market for books, this is a win for authors and publishers. Anyone who's ever shopped for a new car has heard the salesman touting the high resale value of his models, which in turn drives up the price of the new cars. Knowing that I can get something out of a book I decide to sell, I'll be willing to pay more for the new ones.
But, typical of most people today, these idiots only care about how much they can get right now. Who cares about the market they can build for the future?
Sure. The idea is to keep the hardware interface simple, with default behavior that makes sense under any OS/app load. That way, it's an immediate win to implement the hardware, and it doesn't become dated when we shift to the 3.x kernel in a few years (decades, at this rate). The driver is entirely optional, being "aware" of details of your specific setup. I can see the applications for portable computers including a "dump all memory to the cache, set wakeup timer for next cron job, then shutdown" that just wouldn't apply to a server, for instance.
For things like UnixWare, Openserver and *BSD, it'd have to know about the sub-filesystem partitions they use, would they not?
Not that I can see. Ultimately, all of the levels of abstraction map to commands to the HD to read/write one or more LBA sectors. If I want to reserve a specific range of sectors in the cache, all I have to do is use the OS tools that determine what those sector numbers are, and communicate that to the controller. If this means that a device driver would likely be written for a TRAM-enabled controller, sure.
But it's important to keep these things straight: Drivers written for an OS (hopefully source code that can compile under any *nix) may well benefit from knowing about hardware. The controller never needs to know anything about the OS. (And let me reiterate, shouldn't know. Can you say "Win[Modem|Printer]?" Yuck.)
The point of the exercise is to make the system more reliable.
Exactly how does this require that the TRAM have any knowledge of the OS(es) using it?
I am quite well aware of the issues involved in journalling transactions to disk. But once the caching controller has staged the impending writes in its battery-backed RAM,
all the data gets backed up on a persistent medium
just like everyone wants, because the RAM itself is (relatively) persistent. The only downside at all is failure of the battery or the RAM; if you're doing something that critical, it ought to be replicated to multiple servers anyway.
Yes, but doesn't that contradict what you said about a "entirely OS-independent disk controller card"?
No. All the card has to know is that these are the first x sectors that the computer asks for when it boots. It need not (and, I submit, should not) have any knowledge whatsoever of the structure of the filesystem(s) they comprise. All you need is a way to tell the card what you wanted done: Some command that could be sent over the existing bus, but intercepted by the card, to allocate the first N sectors of boot tracks, and hard-map M cylinders for use by a particular partition...
Both boot and swap caching would be most helpful on a [lap|palm]top machine, where epic uptimes are irrelevant. Normally, low-power RAM that is most efficient for battery-backed use is slower than the RAM we're accustomed to using. But it's still orders of magnitude faster than disk access.
The only really new thing here seems to be the fact that the "TRAM" is file-system aware,
I'm still trying to figure out why this is a Good Thing. What is wrong with an entirely OS-independent disk controller card with battery backed write cache.
Whenever your computer told it to write to the disk, the first thing it'd do is write each sector to the cache, and write the drive and LBA sector number to a separate section of memory. The controller could then index this structure by LBA to implement "elevator" writes, vastly improving performance with little risk of data loss.
With enough memory, it could also be configured to permanently cache the MBR, boot loader, kernel, init scripts, daemons... Make it big enough and the whole swap partition is in there, too. Think how fast something like this could boot.
It's as old as computer security itself. This whole controversy about an alleged "flaw" in SSH/SSL is bogus. The weakest link in the chain is the user, who is [un|mis]educated about security. The way that I explain it to the uninitiated is thus:
I can install a solid steel door in your house, with the best deadbolt locks, a top-of-the-line alarm system, and all the bells -n- whistles you can imagine. But if it's too much trouble for you to lock the damned door, none of it does any good. When someone knocks and says "Candygram", it might just be a land shark. We all saw Matthew Broderick read the password off the secretary's desk, defeating whatever security was behind that password.
Can the protocols be fine-tuned to make security holes more obvious to those who know what they mean? Sure. We'll argue about the details of when keys should expire (I say there should be some long-term keys used for nothing other than signing shorter-term keys, for instance), and other minutiae. But I've seen people pay good money to attend classes where the instructor said that "https://" means "you're secure", and left it at that.
Frankly, Joe Average User hasn't had the educational background to question authority, perception of reality, etc. If it looks official, it must be. Like so many other of the issues we discuss here (DeCSS, copy-protected HDs, crypto export restrictions, etc.) we must educate Joe (and Jane) if we ever want to make progress. When was the last time you explained to your semi-computer-literate friends "Email is like a postcard, PGP/GPG is like an envelope"? Widespread use of the Web of Trust model would help make the use of secure protocols as secure as the protocols themselves.
This is a direct challenge to the authority of ICANN to do anything with the domain name system
The authority ICANN enjoys is based entirely on the fact that the overwhelming majority of DNS servers resolve to their designated root servers. There is no law forcing anyone to do so, only the desire we all share to be able to communicate. It seems to me that DNS servers that use "augmented" roots, in the fine tradition of "embrace and extend", do nothing to break the existing domains.
So, if emough operators of DNS servers can be persuaded to do this, and users can be educated as to the benefits, ICANN may one day find its deliberations as relevant as resolutions on global affairs enacted by the Student Council at your local high school.
This means anyone with a driver using the "generic key" will be able to use the file.
I thought of that, but it won't work. The paranoid app will know that it's a "generic key", and refuse to write to that device. It wants to see a unique key (and you can bet your butt the *AA boys will make sure there's a secure channel back to their servers to test uniqueness) before it agrees to use that drive. Hence the double-up dodge: You let the drive report the non-generic key, and give all of the appropriate signals that it's done its job (because it has). You just give it an additional assignment, which it is designed to perform equally well.
As a fairly typical geek, I taught myself HTML, and until recently had no formal training in the (black) art. So last month, I took notice when I sat in a classroom where HTML newbies were encouraged to make their tags UPPERCASE to stand out better, which seemed like a good idea to me.
Being committed to open standards, I've been spending a lot of time on the W3C site, and when this announcement came out, I followed my curiousity to find out what XHTML is... only to find out that XHTML tags are case sensitive! This is a Bad Thing<tm> IMNSHO, because it breaks too many established conventions for no good reason. Maybe it's because I've used terminals that didn't support lower-case letters, back in the Bad Old Days.
The other major difference between HTML 4 and XHTML 1.0 seems to be that every element must explicitly closed, either with a corresponding closing tag, or the self-closing variety: <br/>&Note the space before the closing slash, which older UAs will interpret as an unknown attribute, and therefore ignore, but XML UAs will correctly see as the self-closed element syntax. This is a Good Thing, because it becomes possible to parse a document without any knowledge of which elements require closing tags.
And that is important because the whole point of XML is that it is eXtensible: New tags can be defined and implemented without those annoying
You don't have
Infernal Exploder Version X.YZ or better,
SchlockRave Plugin "Foobar for Morons",
Mutant JavaScript From Hell enabled,
so you suck. Don't come back here until you do, Luzer!
messages. Once you have a UA that does XML, it upgrades its rendering abilities as necessary without opening gaping security holes or requiring a 12-megabyte download and install
Installation Complete. Windows will now restart your computer.
before being able to see some content-free gaudy animated graphic junk on a splash page.
...attack, that is. Since the whole thing is based on the INT 13H interface, it seems to me that a kernel module (or a.DLL for the OS-challenged) can mediate between the application requesting "secure" storage and the drive allocating it.
The easiest thing to do is simply open two files on the drive, one secured and one insecure. Then, whenever the paranoid app asks to write to the secure file, send that block of data to the insecure file, and send the same block to the secure one. Let the challenge/response mechanism built into the drive satisfy the app's desire to assure that it's talking to the Real McCoy, returning the status codes that come back from the secure file to the app.
As an added bonus, throw in the old BBS download quota bypass, and when the last block of data is written, return an error code to the app, indicating that the file is not correctly committed to disk. Also, you can have the app tell the drive to delete the secure file, releasing one "lock" (some supported schemes allow you to make 3 "portable" copies at a time, requiring verified deletion of a copy before another can be made).
Since the interface to the device has to be well-specified, this sort of approach is how the security will be circumvented. Having a copy of the.DLL will be a violation of the DMCA, of course, but so is having pirate copies of movies. Therefore, a version that can be loaded from a floppy will probably be quite popular.
Serial ATA offers about twice as much bandwidth as the current Parallel ATA standard, known as ATA 100. Serial ATA's first incarnation, dubbed Ultra Serial ATA 1500, will offer a peak bandwidth or transfer rate of 1.5 gigabits per second.
"That basically equates to about 150MB of data per second," Ravencraft said. In comparison, Parallel ATA's ATA 100 offers a peak transfer rate of 100MB per second.
Now Slashdot is linking to stories that are wildly inaccurate! 1.5 != 2, for crying out loud! It's important to note that they tried to make SATA sound twice as fast as PATA, because they know that anything less is doomed to failure.
Remember floppies? The 1440 KB variety replaced 720 KB only because they were similarly priced, backward compatible at the hardware level, and doubled capacity. Then 2880 failed to gain acceptance because it failed to deliver the same advantages.
Same thing with the two-sided CD format. The added cost of the hardware will ensure that it is never widely adopted. Unless you can flip the thing over and treat it like a second disk in older drives. Maybe then it will fly.
As a demonstration technology, it will perhaps be interesting, but until the cost is about the same as PATA, and it gets closer to really being "double the bandwidth", I don't look for any better market penetration than, say, ESDI drives with MCA host adapters.
But I can read English. The Fifth Amendment says (emphasis mine):
No person shall be held to answer for a capital, or otherwise infamous crime, unless on a presentment or indictment of a Grand Jury, except in cases arising in the land or naval forces, or in the Militia, when in actual service in time of War or public danger; nor shall any person be subject for the same offence to be twice put in jeopardy of life or limb; nor shall be compelled in any criminal case to be a witness against himself, nor be deprived of life, liberty, or property, without due process of law; nor shall private property be taken for public use, without just compensation.
There are entire books written on the "takings" part, but it's pretty damned clear to me that seizure of personal property without so much as charges being filed isn't exactly "due process".
My last employer bought accounting software in 1996 that was almost completely Y2K compliant. The vendor made no effort to fix the few bugs in their code, but instead generously offered to sell an upgrade to a new version that was supposedly Y2K-OK. If I had access to their source, I could have isolated the bugs, fixed them, and even posted the fixes for others to use, saving others the trouble. Having "someone to blame" doesn't fix bugs, especially when the "blamed" person claims that no bug exists, that your IT people misconfigured the system, or that you didn't hold your mouth just right when you put the CD in.... It just gives lawyers something to yammer about before they read the EULA that says "no warranties....". --------------------
SVM, ERGO MONSTRO.
Slashdot Mirror
As some have pointed out, individuals make the decision to buy a nicer car, TV set, PS2, stereo, cellphone, shoes endorsed by big jocks.... instead of computers. The slight differences in computer ownership that exist today are the result of those choices.
What we as The Community can do is encourage our employers to take the old hardware being replaced in upgrades, and donate it to inner-city schools, churches, community centers, etc... and then bring our LUGs along to do installfests, and train up some new members while we're at it.
This is the second post I've seen modded "offtopic", for pointing out poor grammar/spelling that just shouldn't come from the desk of a CEO.
More importantly, how dare they refer to VA as "Linux", repeatedly throughout the document. Linus' lawyer should sue them for trademark infringement!
The most restrictive readings of the First Amendment say that it only applies to political speech. Perhaps this is because even those who advocate government control of speech recognize the monstrous fundamental contradiction of the regulation of speech (especially of a political nature) by a government that is supposed to be elected by the very people whose access to information is being regulated.
You can try to make the case that children, mentally handicapped people, even convicted criminals as the author of the article suggests, can't handle just any information that's thrown at them. But such controls are always extended to the population at large. If We The People are too damn stupid to judge the information providers ourselves, then how in the fsck are We magically transformed into voters competent to elect people to judge for us all?
But if a (yes, ACs out there who disdain such) commercial distro escorts its users directly into X, and only bothers them when Something Is Seriously Wrong, and that increases the user base of Linux, it's is a Good Thing for us all. Or, we can be arrogant assholes like "Nick Burns, Your Company's Computer Guy" and let MS keep them as customers.
Uh.
Have a bottle of Paul "sell no wine before its time" Masson to celebrate Linus' "we release no kernel before it's time" philosophy.
But even with the Eye Candy, the normal init messages would still be visible in another console, (and a prompt as to what Ctrl-Alt combination brought that one up for the distro in question--or maybe make it really easy and use Esc to switch to the boot messages) but the first time something other than "[OK]" came up, the error message could show up on the Pretty Boot screen (and the prompt might change colors).
This is not even that foreign from the SOP for *nix utilities: Most of them output nothing to the console when they did what you asked, only bothering to tell you when something went wrong. (That's why it's called stderr.) A boot process that shows that progress has been made, and only tells the user what went wrong, sounds like a reasonable setup for most people.
But, typical of most people today, these idiots only care about how much they can get right now. Who cares about the market they can build for the future?
Sure. The idea is to keep the hardware interface simple, with default behavior that makes sense under any OS/app load. That way, it's an immediate win to implement the hardware, and it doesn't become dated when we shift to the 3.x kernel in a few years (decades, at this rate). The driver is entirely optional, being "aware" of details of your specific setup. I can see the applications for portable computers including a "dump all memory to the cache, set wakeup timer for next cron job, then shutdown" that just wouldn't apply to a server, for instance.
Don't like TV ads, either
But the price is right
This shit's getting old
More lawyers than inventors
Try to patent this
[ 8==========> ]
Almost nine pm:
"Screw you guys, I'm going home"
Says Eric Cartman.
[Central Time]
But it's important to keep these things straight: Drivers written for an OS (hopefully source code that can compile under any *nix) may well benefit from knowing about hardware. The controller never needs to know anything about the OS. (And let me reiterate, shouldn't know. Can you say "Win[Modem|Printer]?" Yuck.)
I am quite well aware of the issues involved in journalling transactions to disk. But once the caching controller has staged the impending writes in its battery-backed RAM,
just like everyone wants, because the RAM itself is (relatively) persistent. The only downside at all is failure of the battery or the RAM; if you're doing something that critical, it ought to be replicated to multiple servers anyway.Both boot and swap caching would be most helpful on a [lap|palm]top machine, where epic uptimes are irrelevant. Normally, low-power RAM that is most efficient for battery-backed use is slower than the RAM we're accustomed to using. But it's still orders of magnitude faster than disk access.
Whenever your computer told it to write to the disk, the first thing it'd do is write each sector to the cache, and write the drive and LBA sector number to a separate section of memory. The controller could then index this structure by LBA to implement "elevator" writes, vastly improving performance with little risk of data loss.
With enough memory, it could also be configured to permanently cache the MBR, boot loader, kernel, init scripts, daemons... Make it big enough and the whole swap partition is in there, too. Think how fast something like this could boot.
I can install a solid steel door in your house, with the best deadbolt locks, a top-of-the-line alarm system, and all the bells -n- whistles you can imagine. But if it's too much trouble for you to lock the damned door, none of it does any good. When someone knocks and says "Candygram", it might just be a land shark. We all saw Matthew Broderick read the password off the secretary's desk, defeating whatever security was behind that password.
Can the protocols be fine-tuned to make security holes more obvious to those who know what they mean? Sure. We'll argue about the details of when keys should expire (I say there should be some long-term keys used for nothing other than signing shorter-term keys, for instance), and other minutiae. But I've seen people pay good money to attend classes where the instructor said that "https://" means "you're secure", and left it at that.
Frankly, Joe Average User hasn't had the educational background to question authority, perception of reality, etc. If it looks official, it must be. Like so many other of the issues we discuss here (DeCSS, copy-protected HDs, crypto export restrictions, etc.) we must educate Joe (and Jane) if we ever want to make progress. When was the last time you explained to your semi-computer-literate friends "Email is like a postcard, PGP/GPG is like an envelope"? Widespread use of the Web of Trust model would help make the use of secure protocols as secure as the protocols themselves.
So, if emough operators of DNS servers can be persuaded to do this, and users can be educated as to the benefits, ICANN may one day find its deliberations as relevant as resolutions on global affairs enacted by the Student Council at your local high school.
Being committed to open standards, I've been spending a lot of time on the W3C site, and when this announcement came out, I followed my curiousity to find out what XHTML is... only to find out that XHTML tags are case sensitive! This is a Bad Thing<tm> IMNSHO, because it breaks too many established conventions for no good reason. Maybe it's because I've used terminals that didn't support lower-case letters, back in the Bad Old Days.
The other major difference between HTML 4 and XHTML 1.0 seems to be that every element must explicitly closed, either with a corresponding closing tag, or the self-closing variety: <br />&Note the space before the closing slash, which older UAs will interpret as an unknown attribute, and therefore ignore, but XML UAs will correctly see as the self-closed element syntax. This is a Good Thing, because it becomes possible to parse a document without any knowledge of which elements require closing tags.
And that is important because the whole point of XML is that it is eXtensible: New tags can be defined and implemented without those annoying
messages. Once you have a UA that does XML, it upgrades its rendering abilities as necessary without opening gaping security holes or requiring a 12-megabyte download and install before being able to see some content-free gaudy animated graphic junk on a splash page.The easiest thing to do is simply open two files on the drive, one secured and one insecure. Then, whenever the paranoid app asks to write to the secure file, send that block of data to the insecure file, and send the same block to the secure one. Let the challenge/response mechanism built into the drive satisfy the app's desire to assure that it's talking to the Real McCoy, returning the status codes that come back from the secure file to the app.
As an added bonus, throw in the old BBS download quota bypass, and when the last block of data is written, return an error code to the app, indicating that the file is not correctly committed to disk. Also, you can have the app tell the drive to delete the secure file, releasing one "lock" (some supported schemes allow you to make 3 "portable" copies at a time, requiring verified deletion of a copy before another can be made).
Since the interface to the device has to be well-specified, this sort of approach is how the security will be circumvented. Having a copy of the .DLL will be a violation of the DMCA, of course, but so is having pirate copies of movies. Therefore, a version that can be loaded from a floppy will probably be quite popular.
Remember floppies? The 1440 KB variety replaced 720 KB only because they were similarly priced, backward compatible at the hardware level, and doubled capacity. Then 2880 failed to gain acceptance because it failed to deliver the same advantages.
Same thing with the two-sided CD format. The added cost of the hardware will ensure that it is never widely adopted. Unless you can flip the thing over and treat it like a second disk in older drives. Maybe then it will fly.
As a demonstration technology, it will perhaps be interesting, but until the cost is about the same as PATA, and it gets closer to really being "double the bandwidth", I don't look for any better market penetration than, say, ESDI drives with MCA host adapters.
#include <ianal.h>
But I can read English. The Fifth Amendment says (emphasis mine):
There are entire books written on the "takings" part, but it's pretty damned clear to me that seizure of personal property without so much as charges being filed isn't exactly "due process".My last employer bought accounting software in 1996 that was almost completely Y2K compliant. The vendor made no effort to fix the few bugs in their code, but instead generously offered to sell an upgrade to a new version that was supposedly Y2K-OK. If I had access to their source, I could have isolated the bugs, fixed them, and even posted the fixes for others to use, saving others the trouble. Having "someone to blame" doesn't fix bugs, especially when the "blamed" person claims that no bug exists, that your IT people misconfigured the system, or that you didn't hold your mouth just right when you put the CD in.... It just gives lawyers something to yammer about before they read the EULA that says "no warranties....".
--------------------
SVM, ERGO MONSTRO.