People are already being sent to Linux training (by their employers) in droves in my area.
This should be interesting.
I can't see any kind of training course that effectively teaches someone Linux. You *might* manage to teach someone the GUI configuration front end to Red Hat's current release in a week (including enough background concepts to allow them to understand it). Not much else, though. You definitely can't learn to admin Linux effectively in a week any more than you can learn to admin Windows in a week. I'd go so far as to say that six months of well-thought out curriculum and constant practice probably isn't enough to hammer all the important concepts into someone's head of the workings of just the full set of daemons in a distro, all the important POSIX commands, different security implications, the administrative stuff that a distro uses (keep in mind that this is just for *one* distro) the ins and outs of packge systems, troubleshooting procedures, appropriate forums to go for help and etiquette in those forums, rescue procedures, networking issues...
Maybe it's expecting too much. Most Windows admins that I've run into are barely more than instruction-manual-following monkeys, whereas there are some *scarily* knowledgeable UNIX gurus out there (could be because there are people with thirty years of UNIX experience out there, but none with more than eight of Win95+ experience). You might be able to take a short training course on how to do very basic operation of a system, but if anything breaks, you aren't going to have a *clue* what to do.
God, I've been using Linux heavily for years, and I still don't know standbys like awk (well, just enough to get by, but not much) or anything more than a single operator for sed. I *still* find new commands that I haven't seen before. Groff is a closed book to me. I know a bit of Apache's workings, but not loads. I don't know how to set the systemwide timezone in a distro-independent manner (I could look it up, though). I know almost nothing about sendmail's cf syntax -- without a GUI config frontend, I'd be helpless to get sendmail running, and probably mostly helpless to fix anything more than a basic problem. I don't know what a.la file is. I definitely could not set up a Linux firewall or routing system without *heavily* drawing from a reference work, not like those Cisco gurus can do with their hardware, where they just happily rattle off commands. I don't have a clue how emerge works, or what its drawbacks are. I don't know how to configure Metacity. I've never seen YaST. I barely know any PHP. Perl's objects are a closed book to me. I develop software, and yet it's still a complete mystery to me how people can write autoconf files without painfully slogging through huge masses of GNU documentation and looking for likely candidates and doing days of cutting and pasting and trial and error. I've never used subversion. These are all standard Linux tools that you'll find on a common distribution.
The x85 is one of Lexmark's line of bottom-of-the-barrel, uber-cheap-make-the-money-back-on-ink models, right?
They aren't going to drop one more penny than they have to on the x85. It has to be cheap as heck to make and support. They don't, for example, even bother to support Windows XP according to their website.
Linux to a boss just means change, and change is BAD.
Incidently, this is something that the OSS world can learn from.
Users *hate* user interface change. If you want to change the internals, add features, fine, great. *Don't* move options around or change the way the task is done. For a typical user, this is a huge problem. It's even worse than software randomly blowing their work away -- then they can say "the computer ate it" to their boss, but if they just can't figure out how to do something on version 4, they're the one that gets chewed out.
OSS is both very good and very bad in this respect.
Windows has kept roughly the same interface and way of working with things. They change their widgets around to use the marketing effect of making people using an old OS have a computer that "looks old", but they keep things working basically the same way for typical users. Plus, you can move from Windows machine A to Windows machine B with no problems (but I'll avoid host-based and application-based consistency issues for the moment and just focus on temporal consistency of a piece of software).
Linux is a lot different.
The first time I put Linux on my computer, the first time I used Linux, was Red Hat Linux 5.2 At that point, the GUI was mostly Tk, Athena, and Motif. Navigator used Motif. GV and a couple of other utilites used Athena. All the system configuration stuff was Tk. The window manager was Afterstep (a hacked up version).
Fast forward to Red Hat 6.0. GNOME 1 was introduced (and *boy*, was it flaky at first). IIRC, the login screen was still xdm. Suddenly, users were expected to use GNOME.
Fast forward to Red Hat 8.0 or so. GNOME 2 became the standard interface. I believe the default window manager moved from Enlightenment to Sawfish at this point.
The next release, Metacity became the standard window manager.
The default web browser changed along the way from Navigator 4 to Mozilla to (IIRC galeon for a bit). It's a good guess that it's going to be FireSomething in the next release. The set of basic software and the way to deal with it changes drastically. Most people that I know of that use UNIX find a comfortable way of dealing with it, and then keep doing so. If they like a terminal or a particular window manager, once they've gotten things the way they like, they stick with things. They know how to configure things in newer distros so that everything works the way they like. The typical user just has this bewildering range of changes coming through. How do they get a new file browser window? How do they change the desktop background? How do they switch between windows from the keyboard? These things can't change.
The *good* news is that Linux is configurable enough to *keep* things working pretty much the same way if users like it that way, given a competent admin.
It drives *me* nuts that MS moved the UI method of changing your password and mucking with the network around, among other things, in several of their OS releases.
almost always use UNIX/Linux (and UNIX moreso than Linux) while discussing OS, networking and other systems subjects.
Never have I once come across a mention of Microsoft (except maybe in the History section (Xenix)) any any of the classic books by Tanenbaum, Stevens, et al.
Fair enough...but there's a pragmatic reason for that. Windows is not open source, nor (and here's the biggie) is its architecture nicely laid out with evolution of it easily available. You can say "Minix did this for VM, and today Linux does this for VM, oh, and here are some alternate algorithms currently being tried in research" when you're dealing with *IX. When you do your filesystems bit, there are many filesystems for *IX, and they're open spec and the implementations are open source and people frequently do research work with them. Not the case with NTFS.
So it's a lot easier to write a book about operating system internals if you can, y'know, see the internals.
Re:From sSomeone who pitches those PHB's...
on
Why PHBs Fear Linux
·
· Score: 1
Could it be that many PHB's fear the penguin because of the illogical, emotionally-based arguments so many Linux zealots constantly use to push their agenda?
No. A PHB is going to be talking to some sales guy at Red Hat or maybe SuSE, not to a random Slashdotter. Said sales guy is extremely unlikely to suddenly burst out with "You should use Linux because it lets you FIGHT THE MAN! Oh, and it also is *clearly* what Picard is using on the Enterprise!" right in the middle of sales negotiations.
There are people rabid about (or intensely hating of) Microsoft as well. I'm sure there are some really bizarre characters at Oracle (and Larry Ellison is *high* on that list and *is* visible to your typical MBA).
Linux can even cost a lot, if you so desire!
on
Why PHBs Fear Linux
·
· Score: 5, Funny
You're aware that you can purchase commercial distributions of Linux that are quite pricy, right? Something like Red Hat's high end server product, Red Hat Enterprise Linux Advanced Server starts at $1500, for example. I'm reasonably sure you can find a Linux distributor that will be happy to do business with you if your primary requirement is high cost.
Other benefits of such a classification system could be quite significant. It would be possible (and probably not very difficult) to produce tools for a runtime environment, such as a JVM or kernel, to enforce compliance.
Looking at my example from above:
a) The software bounds-checks all memory accesses to data at the compiler level (free with some languages like Java, and can be done in C if necessary).
b) The software does not access the network.
c) The software does not write to any data files.
(b) and (c) would be very easy to implement at the kernel level, and would potentially make a good capability (I believe all the POSIX capabilities extend, rather than restrict, privileges, which is a bit unfortunate for those who would like to use the kernel to sandbox processes). Windows *may* already be able to do this, and since this is a common requirement for a trusted system, it's a good bet that some trusted Linux projects already implement enough kernel support to handle this.
Yup, that was pretty much my take on things (Rule 1: industry *never* asks for regulation without an ulterior motive), although I think that there's a bit more to it -- if any cronyism can be used by existing players, it might be a useful tool against challengers, forgetting about Open Source for a moment.
I'm all for the government issuing advisories, but regulation of security is not feasible. I remember reading about older military software -- the government used to try to do much more comprehensive security reviews of all kinds of software it used with tiger teams. Unfortunately, it turned out the extreme expense of this kind of thing isn't feasible in the real world, and still left holes.
If I had to give a government recommendation, it would probably be along the lines of:
* Issue advisiories. There are organizations like CERT that do this. Unbiased (not from a vendor), trustworthy information is difficult to come by.
* Issue best-practices papers. These are probably most useful to IT professionals, though it might even be a good idea to produce them for software developers. Microsoft recently collaborated with the Fed to produce a set of best security practicees documents for Windows. This is an easy thing to add to a company security policy ("[] must comply with USG Document #135F3 Best Practices"). It just tried to deal with a couple of common misconfigurations. It's *hard* to get this kind of stuff directly from a vendor (which frequently wants to hand out information that will encourage you to buy more or is more interested in putting a positive spin on their mistakes) or a consultant (who frequently wants you to buy more consulting services) or a security software (like a firewall) company, which is primarily interested in scaring companies into thinking that they need security software.
* Government certification of software intended for non-government use is a bad idea. It takes a long time, allows cronyism, can be used to attack some sections of the market (like most Open Source). It's perfectly reasonable for USG-use purchase requirements, but it's not reasonable for broader use.
* Producing a classification system *could* be very useful, where the government writes documents describing particular classes of software, but it not responsible for ensuring that a particular version of a program fits into a class of software. For example, a hypothetical class-local/1 might require that:
a) The software bounds-checks all memory accesses to data at the compiler level (free with some languages like Java, and can be done in C if necessary).
b) The software does not access the network.
c) The software does not write to any data files.
Others useful requirements for various classes of software might be: "The software does not provide privilege escalation within the UNIX operating system's privilege system (as a suid/sgid program or a daemon running as a different user does...there would be an equivalent for the Windows security system)", "All data that the software uses from the network is either exact-match checked or bounds-checked prior to use of any of that data, and a failure to pass checks results in that data not being used" (might be useful for simple network software, like clients of the daytime protocol). The government is great at writing requirements and making them publically available--let's use that. Then, if a company guarantees that they are compliant to a particular document in a contract, there is a clear point that they can be called on for non-compliance. Finally, there would be a market for software that can check software for some elements of compliance. Automated security checking is a major issue -- it's neat, it's more and more feasible (see CMU's Java proof-carrying compiler for some neat stuff. The problem is that there are currently no standards written by security folks who know what they're doing, so it's hard for businesses to ask for compliance to a particular level of security, and no tools that can certify programs to a particular level.
There are probably a lot more suggestions that the government could use, but this is a start...
Yeah, this'll be *real* useful. A database with entries that become obsolete after eight hours. "There's a Linux kernel vulnerability, and it...aw, darn.";-)
"the learning curve for the API's to both UNIX and Windows has become...daunting. Short of going back to school, what would you soon to be fellow geeks recommend as a good kick start?"
*I* want to know how much UNIX C APIs have changed since the 70s. It can't be *that* much.
Well, I had seen them before, but I didn't know they were Anime fans since they don't run around wearing Gundam t-shirts. Anyway, they were discussing quirks of Japanese culture and the prevalence of tentacles.
Not true. The SEC does have some sort of jurisdiction (sorry, not an investment broker) over companies that are in the process of becoming public. There is a lead-up phase to going publically traded where certain behavior is not allowed, like doing certain types of press releases.
I have no idea whether this is an April Fool's Day joke or not. Slashdot *did* post this on March 31rd, so if it is an April Fool's Day joke, it wasn't scheduled very well.
It's also fairly financially feasible to have 1GB email accounts (something that used to drive me *nuts* with the IT people at the company I used to work for -- why do these people insist on 100MB email quotas?) 1GB is what, about 30 cents of storage in terms of physical media costs? Can't be *too* hard to make back in terms of marketing data that you can make on each person in the system, what their interests are, who they interact with, how trends spread, etc. You figure that Google is going to go for a cheap system, that access time and bandwidth doesn't need to be especially high, that they can compress spam very efficiently (any similarity between letters in multiple boxes gets ironed out) and the fact that most people aren't going to be using a full GB, and I'd say that this could certainly be done.
This is *especially* true in the case of Blizzard, which has an exceptional marketing engine.
I remember them working on building up fervor about Starcraft. Not that Starcraft was a bad game, but they had a huge amount of misleading and exaggerated claims about the abilities of the engine.
I don't see why anyone cares about a game like WoW before it comes out. Ignore it until the release, then read a review or two or take a look at the forums and think about whether you want it. Blizzard beta releases are more about hype than testing.
FedEx has reliability issues in some situations. In the event of, say, a war that damages road/bridges and airports (i.e. just about any modern war), FedEx will be among the first things to go. Pigeons are very difficult to completely stop.
One time, this guy with white earbuds saw my iPod and gave me the knowing "hey there fellow iPod user" nod and started running on the machine next to mine.
Ah, this is a "hey there fellow iPod user" nod, and not one of those generic "hey there fellow MP3 player user" nod? I so frequently confuse those...
Anybody who would spend $400 bucks on an audio player and then use the $5 stock buds (and I don't care what apple sells them for) that came with the player needs to be separated from said expensive player *immediately*. Watching someone use those crappy stock buds is like watching a 16-year old getting driving lessons in a Lamborghini Murcielago.
For Chrissake, they are not an audiophile. They are listening to lossily-compressed MP3s. Any person that spends tons of money on expensive headphones for their iPod is not an audiophile, they're just looking for a damned status symbol. (IMHO most people that purchase iPods in the first place are looking for a status symbol, but such is life.)
Googling yielded a $200 handgun easily. Of course, you aren't going to be doing fancy target shooting with said gun, but it probably does a reasonable job of rapidly shoving a piece of metal into someone nearby.
First off, you obviously don't live in Texas. You can shoot people for a lot of things there, including stealing your car (assuming they're on your property).
Fair enough. Texas was actually the reason I used "*almost* all circumstances" -- there might be other states with exceptions, but Texas is the only one I know of. (Actually, I thought that Texas only let you do so during nighttime burglary and robbery, but looking up the actual text, it looks like it's much more broadly defined).
Second, I didn't expect that you'd shoot someone in the back, but I had to mention it as part of covering all points -- the obvious issue during the crime is risk to yourself, and after the crime the legal issues. If you're in Texas, though, you can get away with it (I remember a case where a repo man was fatally shot in Texas while leaving a house with a car he had just repossessed. The attorney general refused to press charges. When asked what the repo man should have done differently, since he was simply carrying out his job, the AG gave the memorable quote "well, I guess he should have been faster.")
I'm sorry -- I was being sarcastic, but the vitriol was really aimed at the PTO ("one would have to be innocent to assume that an incredibly idiotic patent wouldn't get through"), not you.
What I meant was that the idea of using checksumming and encryption in cookies cannot be patented.
That certainly could be true, but it's not what you wrote in your original post:
You could return a cookie from a pool of cookies received by other people at other times. If you can guess the method of checksumming and encryption, you can make your own.
If you're guessing the method, you're not concerned with just the idea -- you're concerned with the exact same mechanism that they're using.
You only need a concealed carry permit if the gun is concealed. You can carry a gun in the open without any legal problems (though I had one extremely pro-gun-rights professor once ask a police officer what she'd do if he walked around downtown with a loaded shotgun slung over his back and she said that she'd probably end up arresting him for disturbing the peace or something.)
Our founding fathers agreed that the second amendment was not a provision for militia, but truly the right for American citizens to protect themselves.
"A well regulated Militia, being necessary to the security of a free State, the right of the people to keep and bear Arms, shall not be infringed." (in our Founding Fathers' own words -- what the Supreme Court may have felt later about the amendment may play better into your interpretation.)
The purpose of the second amendment probably has a lot of reasons, but I'm not entirely sure how you reach your conclusion. The way I've always seen it presented is as a final check to avoid an oppressive government from being imposed -- if 80% of the people out there are angry and upset enough about the government to risk their lives fighting against it, that government will not be in place long, just as happened in the American Revolution.
I nearly choked when I saw this. Looks like we need some figures...
Call me silly, but why didn't you give *mugging*-related figures instead of *murder*-related figures? What does the fact that some guy got poisoned for his life insurance by his wife have to do with muggings at all?
Neal Stephenson makes a good point in Snow Crash -- pepper spray, in most situations, is more effective than a gun. You get hit in the face with pepper spray, you aren't going anywhere except for on the ground rubbing your eyes and yelling.
That doesn't mean that a gun doesn't have a point -- just that its nonlethal buddy is frequently overlooked.
Slashdot Mirror
People are already being sent to Linux training (by their employers) in droves in my area.
.la file is. I definitely could not set up a Linux firewall or routing system without *heavily* drawing from a reference work, not like those Cisco gurus can do with their hardware, where they just happily rattle off commands. I don't have a clue how emerge works, or what its drawbacks are. I don't know how to configure Metacity. I've never seen YaST. I barely know any PHP. Perl's objects are a closed book to me. I develop software, and yet it's still a complete mystery to me how people can write autoconf files without painfully slogging through huge masses of GNU documentation and looking for likely candidates and doing days of cutting and pasting and trial and error. I've never used subversion. These are all standard Linux tools that you'll find on a common distribution.
This should be interesting.
I can't see any kind of training course that effectively teaches someone Linux. You *might* manage to teach someone the GUI configuration front end to Red Hat's current release in a week (including enough background concepts to allow them to understand it). Not much else, though. You definitely can't learn to admin Linux effectively in a week any more than you can learn to admin Windows in a week. I'd go so far as to say that six months of well-thought out curriculum and constant practice probably isn't enough to hammer all the important concepts into someone's head of the workings of just the full set of daemons in a distro, all the important POSIX commands, different security implications, the administrative stuff that a distro uses (keep in mind that this is just for *one* distro) the ins and outs of packge systems, troubleshooting procedures, appropriate forums to go for help and etiquette in those forums, rescue procedures, networking issues...
Maybe it's expecting too much. Most Windows admins that I've run into are barely more than instruction-manual-following monkeys, whereas there are some *scarily* knowledgeable UNIX gurus out there (could be because there are people with thirty years of UNIX experience out there, but none with more than eight of Win95+ experience). You might be able to take a short training course on how to do very basic operation of a system, but if anything breaks, you aren't going to have a *clue* what to do.
God, I've been using Linux heavily for years, and I still don't know standbys like awk (well, just enough to get by, but not much) or anything more than a single operator for sed. I *still* find new commands that I haven't seen before. Groff is a closed book to me. I know a bit of Apache's workings, but not loads. I don't know how to set the systemwide timezone in a distro-independent manner (I could look it up, though). I know almost nothing about sendmail's cf syntax -- without a GUI config frontend, I'd be helpless to get sendmail running, and probably mostly helpless to fix anything more than a basic problem. I don't know what a
The x85 is one of Lexmark's line of bottom-of-the-barrel, uber-cheap-make-the-money-back-on-ink models, right?
They aren't going to drop one more penny than they have to on the x85. It has to be cheap as heck to make and support. They don't, for example, even bother to support Windows XP according to their website.
Linux to a boss just means change, and change is BAD.
Incidently, this is something that the OSS world can learn from.
Users *hate* user interface change. If you want to change the internals, add features, fine, great. *Don't* move options around or change the way the task is done. For a typical user, this is a huge problem. It's even worse than software randomly blowing their work away -- then they can say "the computer ate it" to their boss, but if they just can't figure out how to do something on version 4, they're the one that gets chewed out.
OSS is both very good and very bad in this respect.
Windows has kept roughly the same interface and way of working with things. They change their widgets around to use the marketing effect of making people using an old OS have a computer that "looks old", but they keep things working basically the same way for typical users. Plus, you can move from Windows machine A to Windows machine B with no problems (but I'll avoid host-based and application-based consistency issues for the moment and just focus on temporal consistency of a piece of software).
Linux is a lot different.
The first time I put Linux on my computer, the first time I used Linux, was Red Hat Linux 5.2 At that point, the GUI was mostly Tk, Athena, and Motif. Navigator used Motif. GV and a couple of other utilites used Athena. All the system configuration stuff was Tk. The window manager was Afterstep (a hacked up version).
Fast forward to Red Hat 6.0. GNOME 1 was introduced (and *boy*, was it flaky at first). IIRC, the login screen was still xdm. Suddenly, users were expected to use GNOME.
Fast forward to Red Hat 8.0 or so. GNOME 2 became the standard interface. I believe the default window manager moved from Enlightenment to Sawfish at this point.
The next release, Metacity became the standard window manager.
The default web browser changed along the way from Navigator 4 to Mozilla to (IIRC galeon for a bit). It's a good guess that it's going to be FireSomething in the next release. The set of basic software and the way to deal with it changes drastically. Most people that I know of that use UNIX find a comfortable way of dealing with it, and then keep doing so. If they like a terminal or a particular window manager, once they've gotten things the way they like, they stick with things. They know how to configure things in newer distros so that everything works the way they like. The typical user just has this bewildering range of changes coming through. How do they get a new file browser window? How do they change the desktop background? How do they switch between windows from the keyboard? These things can't change.
The *good* news is that Linux is configurable enough to *keep* things working pretty much the same way if users like it that way, given a competent admin.
It drives *me* nuts that MS moved the UI method of changing your password and mucking with the network around, among other things, in several of their OS releases.
almost always use UNIX/Linux (and UNIX moreso than Linux) while discussing OS, networking and other systems subjects.
Never have I once come across a mention of Microsoft (except maybe in the History section (Xenix)) any any of the classic books by Tanenbaum, Stevens, et al.
Fair enough...but there's a pragmatic reason for that. Windows is not open source, nor (and here's the biggie) is its architecture nicely laid out with evolution of it easily available. You can say "Minix did this for VM, and today Linux does this for VM, oh, and here are some alternate algorithms currently being tried in research" when you're dealing with *IX. When you do your filesystems bit, there are many filesystems for *IX, and they're open spec and the implementations are open source and people frequently do research work with them. Not the case with NTFS.
So it's a lot easier to write a book about operating system internals if you can, y'know, see the internals.
Could it be that many PHB's fear the penguin because of the illogical, emotionally-based arguments so many Linux zealots constantly use to push their agenda?
No. A PHB is going to be talking to some sales guy at Red Hat or maybe SuSE, not to a random Slashdotter. Said sales guy is extremely unlikely to suddenly burst out with "You should use Linux because it lets you FIGHT THE MAN! Oh, and it also is *clearly* what Picard is using on the Enterprise!" right in the middle of sales negotiations.
There are people rabid about (or intensely hating of) Microsoft as well. I'm sure there are some really bizarre characters at Oracle (and Larry Ellison is *high* on that list and *is* visible to your typical MBA).
You're aware that you can purchase commercial distributions of Linux that are quite pricy, right? Something like Red Hat's high end server product, Red Hat Enterprise Linux Advanced Server starts at $1500, for example. I'm reasonably sure you can find a Linux distributor that will be happy to do business with you if your primary requirement is high cost.
Other benefits of such a classification system could be quite significant. It would be possible (and probably not very difficult) to produce tools for a runtime environment, such as a JVM or kernel, to enforce compliance.
Looking at my example from above:
a) The software bounds-checks all memory accesses to data at the compiler level (free with some languages like Java, and can be done in C if necessary).
b) The software does not access the network.
c) The software does not write to any data files.
(b) and (c) would be very easy to implement at the kernel level, and would potentially make a good capability (I believe all the POSIX capabilities extend, rather than restrict, privileges, which is a bit unfortunate for those who would like to use the kernel to sandbox processes). Windows *may* already be able to do this, and since this is a common requirement for a trusted system, it's a good bet that some trusted Linux projects already implement enough kernel support to handle this.
Yup, that was pretty much my take on things (Rule 1: industry *never* asks for regulation without an ulterior motive), although I think that there's a bit more to it -- if any cronyism can be used by existing players, it might be a useful tool against challengers, forgetting about Open Source for a moment.
I'm all for the government issuing advisories, but regulation of security is not feasible. I remember reading about older military software -- the government used to try to do much more comprehensive security reviews of all kinds of software it used with tiger teams. Unfortunately, it turned out the extreme expense of this kind of thing isn't feasible in the real world, and still left holes.
If I had to give a government recommendation, it would probably be along the lines of:
* Issue advisiories. There are organizations like CERT that do this. Unbiased (not from a vendor), trustworthy information is difficult to come by.
* Issue best-practices papers. These are probably most useful to IT professionals, though it might even be a good idea to produce them for software developers. Microsoft recently collaborated with the Fed to produce a set of best security practicees documents for Windows. This is an easy thing to add to a company security policy ("[] must comply with USG Document #135F3 Best Practices"). It just tried to deal with a couple of common misconfigurations. It's *hard* to get this kind of stuff directly from a vendor (which frequently wants to hand out information that will encourage you to buy more or is more interested in putting a positive spin on their mistakes) or a consultant (who frequently wants you to buy more consulting services) or a security software (like a firewall) company, which is primarily interested in scaring companies into thinking that they need security software.
* Government certification of software intended for non-government use is a bad idea. It takes a long time, allows cronyism, can be used to attack some sections of the market (like most Open Source). It's perfectly reasonable for USG-use purchase requirements, but it's not reasonable for broader use.
* Producing a classification system *could* be very useful, where the government writes documents describing particular classes of software, but it not responsible for ensuring that a particular version of a program fits into a class of software. For example, a hypothetical class-local/1 might require that:
a) The software bounds-checks all memory accesses to data at the compiler level (free with some languages like Java, and can be done in C if necessary).
b) The software does not access the network.
c) The software does not write to any data files.
Others useful requirements for various classes of software might be: "The software does not provide privilege escalation within the UNIX operating system's privilege system (as a suid/sgid program or a daemon running as a different user does...there would be an equivalent for the Windows security system)", "All data that the software uses from the network is either exact-match checked or bounds-checked prior to use of any of that data, and a failure to pass checks results in that data not being used" (might be useful for simple network software, like clients of the daytime protocol). The government is great at writing requirements and making them publically available--let's use that. Then, if a company guarantees that they are compliant to a particular document in a contract, there is a clear point that they can be called on for non-compliance. Finally, there would be a market for software that can check software for some elements of compliance. Automated security checking is a major issue -- it's neat, it's more and more feasible (see CMU's Java proof-carrying compiler for some neat stuff. The problem is that there are currently no standards written by security folks who know what they're doing, so it's hard for businesses to ask for compliance to a particular level of security, and no tools that can certify programs to a particular level.
There are probably a lot more suggestions that the government could use, but this is a start...
Yeah, this'll be *real* useful. A database with entries that become obsolete after eight hours. "There's a Linux kernel vulnerability, and it...aw, darn." ;-)
"the learning curve for the API's to both UNIX and Windows has become...daunting. Short of going back to school, what would you soon to be fellow geeks recommend as a good kick start?"
*I* want to know how much UNIX C APIs have changed since the 70s. It can't be *that* much.
Well, I had seen them before, but I didn't know they were Anime fans since they don't run around wearing Gundam t-shirts. Anyway, they were discussing quirks of Japanese culture and the prevalence of tentacles.
:-)
And you say this posting on April 1st?
Not true. The SEC does have some sort of jurisdiction (sorry, not an investment broker) over companies that are in the process of becoming public. There is a lead-up phase to going publically traded where certain behavior is not allowed, like doing certain types of press releases.
I have no idea whether this is an April Fool's Day joke or not. Slashdot *did* post this on March 31rd, so if it is an April Fool's Day joke, it wasn't scheduled very well.
It's also fairly financially feasible to have 1GB email accounts (something that used to drive me *nuts* with the IT people at the company I used to work for -- why do these people insist on 100MB email quotas?) 1GB is what, about 30 cents of storage in terms of physical media costs? Can't be *too* hard to make back in terms of marketing data that you can make on each person in the system, what their interests are, who they interact with, how trends spread, etc. You figure that Google is going to go for a cheap system, that access time and bandwidth doesn't need to be especially high, that they can compress spam very efficiently (any similarity between letters in multiple boxes gets ironed out) and the fact that most people aren't going to be using a full GB, and I'd say that this could certainly be done.
Nothing ever lives up to hype.
This is *especially* true in the case of Blizzard, which has an exceptional marketing engine.
I remember them working on building up fervor about Starcraft. Not that Starcraft was a bad game, but they had a huge amount of misleading and exaggerated claims about the abilities of the engine.
I don't see why anyone cares about a game like WoW before it comes out. Ignore it until the release, then read a review or two or take a look at the forums and think about whether you want it. Blizzard beta releases are more about hype than testing.
FedEx has reliability issues in some situations. In the event of, say, a war that damages road/bridges and airports (i.e. just about any modern war), FedEx will be among the first things to go. Pigeons are very difficult to completely stop.
One time, this guy with white earbuds saw my iPod and gave me the knowing "hey there fellow iPod user" nod and started running on the machine next to mine.
Ah, this is a "hey there fellow iPod user" nod, and not one of those generic "hey there fellow MP3 player user" nod? I so frequently confuse those...
Anybody who would spend $400 bucks on an audio player and then use the $5 stock buds (and I don't care what apple sells them for) that came with the player needs to be separated from said expensive player *immediately*. Watching someone use those crappy stock buds is like watching a 16-year old getting driving lessons in a Lamborghini Murcielago.
For Chrissake, they are not an audiophile. They are listening to lossily-compressed MP3s. Any person that spends tons of money on expensive headphones for their iPod is not an audiophile, they're just looking for a damned status symbol. (IMHO most people that purchase iPods in the first place are looking for a status symbol, but such is life.)
Googling yielded a $200 handgun easily. Of course, you aren't going to be doing fancy target shooting with said gun, but it probably does a reasonable job of rapidly shoving a piece of metal into someone nearby.
First off, you obviously don't live in Texas. You can shoot people for a lot of things there, including stealing your car (assuming they're on your property).
Fair enough. Texas was actually the reason I used "*almost* all circumstances" -- there might be other states with exceptions, but Texas is the only one I know of. (Actually, I thought that Texas only let you do so during nighttime burglary and robbery, but looking up the actual text, it looks like it's much more broadly defined).
Second, I didn't expect that you'd shoot someone in the back, but I had to mention it as part of covering all points -- the obvious issue during the crime is risk to yourself, and after the crime the legal issues. If you're in Texas, though, you can get away with it (I remember a case where a repo man was fatally shot in Texas while leaving a house with a car he had just repossessed. The attorney general refused to press charges. When asked what the repo man should have done differently, since he was simply carrying out his job, the AG gave the memorable quote "well, I guess he should have been faster.")
I'm sorry -- I was being sarcastic, but the vitriol was really aimed at the PTO ("one would have to be innocent to assume that an incredibly idiotic patent wouldn't get through"), not you.
What I meant was that the idea of using checksumming and encryption in cookies cannot be patented.
That certainly could be true, but it's not what you wrote in your original post:
You could return a cookie from a pool of cookies received by other people at other times. If you can guess the method of checksumming and encryption, you can make your own.
If you're guessing the method, you're not concerned with just the idea -- you're concerned with the exact same mechanism that they're using.
Spend $260 on a pair of Etymotic 4Ps and you won't listen to those POS white headphones again.
Of course, then your life sucks when the cable gets damaged from you jogging with them in and it getting bent and tugged at...
You only need a concealed carry permit if the gun is concealed. You can carry a gun in the open without any legal problems (though I had one extremely pro-gun-rights professor once ask a police officer what she'd do if he walked around downtown with a loaded shotgun slung over his back and she said that she'd probably end up arresting him for disturbing the peace or something.)
Our founding fathers agreed that the second amendment was not a provision for militia, but truly the right for American citizens to protect themselves.
"A well regulated Militia, being necessary to the security of a free State, the right of the people to keep and bear Arms, shall not be infringed." (in our Founding Fathers' own words -- what the Supreme Court may have felt later about the amendment may play better into your interpretation.)
The purpose of the second amendment probably has a lot of reasons, but I'm not entirely sure how you reach your conclusion. The way I've always seen it presented is as a final check to avoid an oppressive government from being imposed -- if 80% of the people out there are angry and upset enough about the government to risk their lives fighting against it, that government will not be in place long, just as happened in the American Revolution.
You're right, of course, although you have to admit it'd be terribly risky to try pulling a gun while you have a gun aimed at your head.
I nearly choked when I saw this. Looks like we need some figures...
Call me silly, but why didn't you give *mugging*-related figures instead of *murder*-related figures? What does the fact that some guy got poisoned for his life insurance by his wife have to do with muggings at all?
Neal Stephenson makes a good point in Snow Crash -- pepper spray, in most situations, is more effective than a gun. You get hit in the face with pepper spray, you aren't going anywhere except for on the ground rubbing your eyes and yelling.
That doesn't mean that a gun doesn't have a point -- just that its nonlethal buddy is frequently overlooked.