The real security concern with VMs is duplication... if you clone a bunch of VMs but they start with the same entropy pool, then generate an SSL cert after clone, the other SSL certs will be easily predicted.
Yeah, I encountered that the other day. Built a VM, took a snapshot, did some stuff, reverted, did the same stuff. I was testing a procedure doc I was writing. Part of the procedure was creating an SSL cert, and I got an identical one on both attempts. That seems a little fishy to me; I would expect the certs to be (by the standards of cryptography) very similar, not identical. With that said, I didn't actually generate the cert myself, I ran a script (which I didn't write) to do it. The script might be using the same random seed or something. Or it could be a characteristic of moznss.
Feeling good about your EC2 instances, eh?
No shit. It might be worthwhile to use your desktop or some other hardware you control to seed your VM's PRNG with higher-quality entropy. That way, you should at least be able to avoid collisions with other VMs on the same hardware.
That's a great idea, but the problem is that the cost of digital reproduction is near enough zero as makes no difference. If you publish an e-book, and I buy a copy for $5, why would anyone else buy a copy when they could get one for free from me? Some people would do it out of habit. Others would do it because they feel it's the honest thing to do. But most people would not. I've got to imagine that it would be really hard to make a living this way.
You'd probably have to switch to a Kickstarter-like model. The prospective author uploads a high-level summary of what he wants to write. People who want to read it donate a couple bucks. The author then writes something and releases it for free. This would probably work, at least in a sense, but it'd be hard to fund longer works this way. You'd get a lot of short stories, novellas, and serials. I've got nothing against those formats, but I do like to have some diversity.
Philosophically, we're both in total agreement. I really only have a problem with how it would work (or not) in practice. I think a more realistic solution would be to have copyright, just like we do now, but with a drastically reduced term. Like, one year by default, up to a maximum of five years if you apply for an extension each year. If you can't break even on your copyrighted work in less than five years, you're never going to. If people are willing to wait for your copyright to expire rather than buying now, your work isn't important enough to deserve protection.
The herbicide in question -- Roundup, aka glyphosate -- kills plants that aren't genetically modified to be resistant to it. If you plant a bunch of non-GM corn and then spray the whole thing with Roundup, you will kill everything, including the corn. So yeah, I can't imagine any reason a farmer would be doing that either.
seriously, the bootloader on modern hardware doesn't need all that bullshit.
Yes, it does need "all that bullshit." Booting from anything except an on-board hard disk controller on a PC BIOS is a hackjob. It's just an absolutely horrible clusterfuck. The fact that it ever works at all is a testament to the hard work put in over the past 20+ years by all the bootable expansion card makers.
I'm not trying to be a dick, but your comment really makes me think that you've never used anything except a desktop PC. In the server world, you always boot from an expansion card -- note that onboard NICs count as expansion cards in this context, because the BIOS can't boot from them directly; it has to pass control to the NIC's BIOS, which handles PXE -- at least once in the server's life to kickstart it. And there are a good number of situations where you never boot from a local hard disk. That's not just PXE. It also includes iSCSI and FC HBAs, ROMs or flash devices, RAID controllers, and probably a raft of things that I've simply never encountered.
I think that OpenBoot would've been a better choice than UEFI, personally. But I don't think any knowledgeable person can dispute the need for something better than the 1980s-era PC BIOS.
Ultimately, I think the compromise that we will get is that you will be able to resell used games, and you, the distributor, and the publisher will all get a cut. It's unfair for the publisher to get anything -- it doesn't right now, with physical media-only resales -- but you know they will fight and fight to prevent resales at all. The only way they'll ever agree to it is if they get something in return. Unfair though it might be, I don't see any solution that doesn't result in them getting a piece of the action.
The great thing is that digitally-distributed games are fungible. There's no difference between my used copy and your used copy, or even between a used copy and a new one. This means that you can handle them exactly the same way we handle stocks, bonds, and commodities, all of which are fungible too. It makes pricing largely automatic. Pricing could actually be made completely automatic, although it would work better if you at least let sellers put in bids manually.
I'd love to see an email app that complies with IT demands for a PIN lock, encryption, and remote wipe capabilities without turning those features on for the entire phone. I don't want to enter a goddamn PIN code just so I can play Zookeeper Battle. I don't need to encrypt the pictures of my wife and kid I have on my phone. And I don't think IT really cares if my Plants vs. Zombies achievements get stolen by a hacker.
I mean, I still wouldn't buy a Blackberry device. But that strikes me as an actual business-related value-add they could offer. All the other stuff people are talking about here -- "connect to an Exchange server" and "view Excel spreadsheets" seem to be the most common -- can already be done by every other phone in existence. Those aren't awesome things your BB does. Those are basic, entry-level features that any modern smartphone must have.
My car's approach is that pulling on the door handle twice from the inside will unlock (and open) the door. I wouldn't precisely call it intuitive, but it doesn't take long to figure out either. Actually, I think it is intuitive, it's just that people are so used to having to unlock the doors another way (push a button, flip a switch, pull a knob, whatever) that they don't expect it and therefore become confused.
BMW's rationale is that when you're in a panic situation -- on fire, sinking in a lake, etc. -- you're just going to pull on the handle until the door opens. It's a pretty decent idea. The problem, and it's a big one, is that it's probably electrical. So if the car loses power for some reason, you wouldn't be able to open the door. It could probably be done mechanically, though. For all I know it is.
The issues with not being able to delete a menu entry is due most of the time to users attempting to certain things as root inside their home directory. Hence, when certain files are created they end up with root permissions (meaning you need root to modify them). I suspect this is what happened in your/your friend's case.
But that demonstrates two (and possibly three) UI failures:
The UI should not give you the option to try something that isn't possible (such as deleting a file in a directory to which you have no write permission). (This is the one that might not be a failure.)
The UI should, when this happens, give you an informative error message that explains exactly what went wrong and (ideally) how to fix it. Silent failure is always a bug, and a very major one. There's absolutely no excuse for the menu editor not saying, at the very least, "Permission denied." It should really say:
The menu entry "app-name-here" cannot be deleted because you do not have write permission to the folder which contains the entry.
This ties in to the next point...
When the editor needs special permissions to perform an operation, it should ask for them. So the above error message ought to contain a button that says something like "Reset permissions." Actually, I would like it to be harder to get to than that, because it's possible that there's a good reason the user doesn't have permission. Perhaps the help button for the above error could tell you to right-click on the containing folder and click something there. Although that's another questionable UI decision, namely, "If the computer knows how to fix a problem, it should fix it itself without its hand being held."
Of course, there is also a problem with the application putting root-owned crap in the user's home directory. That's usually a design error with "legacy" apps that reinvent the configuration-storing wheel. (You should be using the APIs provided by GNOME, KDE, or whatever else.)
According to WP, DOS 2.0 introduced directories. The reason for using the forward slash to indicate options is probably that DCL from (Open)VMS does it that way. Note that, just like in DCL, the forward slash is a special character to the command interpreter, which will automatically start a new argument to the invoked program or function. In other words, arguments will be split by the interpreter at forward slashes.
Of course, this doesn't explain why they used backslashes. If they were modeling DOS after VMS, they'd have used dollar signs or colons or some other craziness. It's almost like they hired a bunch of VMS junkies, settled on forward slashes for switches, fired all the VMS wizards and replaced them with Unix gurus, then introduced directories.
As far as I know, there's nothing prohibiting a gradual gauge change over time and space.
No, but presumably there will be a way to describe that change. I mean, it's quite possible we're already doing it without really being aware. And that's kind of the problem: we're inside the universe, so we have no objective view of it. We can't see it changing, because change is by definition relative to something else and we have nothing else for comparison.
My personal crazy belief is that we "force" the universe into sense. We don't really change it, we simply change our perceptions until the universe seems perfectly logical and natural. If the universe were to change suddenly in some unexpected and strange way, then we would simply change our perceptions of it until it made sense again. It's kind of like how insane people will build perfectly consistent internal worldviews which are utterly mad from the perspective of others. Well, not kind of like, exactly like. It's also doublethink, of course, but humans do that all the time anyway.
It's not entirely crazy, though. Evolution would play a part in it. Why does the universe sometimes seem a little too orderly, a little too logical? Because, of course, we have evolved to live in the universe. We wouldn't be viable as a species if the universe were unpredictable and changing all the time. So whatever little tweaks in our DNA were required in order for us to make sense of this chaotic place, we got. We are, in essence, wired at a very fundamental level to think the same way as the universe. So naturally (literally) it all can sometimes seem so clear and... well, planned.
(Yes, I was being vaguely ironic at the end there. Yes, I realize it sounds like I'm talking about God, just using the word "universe" instead. No, I'm not actually saying that, though I believe that if there is such an entity, that's the shape it'd have to take.)
in regards to the bit about scouts, snipers, heavies, engies, etc...it's almost as if each class has certain strengths and weaknesses put in there intentionally! I know it sounds crazy, but maybe, just *maybe*, there's more of a difference to each class than the character model! WOW!
I think it was more a commentary on the relative popularity of the classes than their strengths and weaknesses. For example, if you look at the full stats from Valve, you'll see that scouts are the most popular class, but also one of the least effective (fourth-worst in points gained, second-worst in kills earned). Looking at it from the other side, heavies are probably the most effective class overall, but they're the fourth-least popular class. Unsurprisingly to anyone who's ever played TF2, medics are the least popular class by a wide margin -- but they are also the entire reason that heavies are so good, and that's reflected in their scores (almost three times as many assists per hour as the next-highest class, and it's enough to make them get more points per hour than demos and engineers, and almost scouts!).
My only gripe about TF2 has nothing to do with the game, and everything to do with the players. I always end up being a medic because nobody else will do it. I don't get it. Medic is by far the easiest class to play. You'd expect the noobs to gravitate to it, just like they do in CS to the AWP (the easiest gun in the game, since it's the only one that shoots straight). Yet they choose probably the hardest class -- scout -- for some reason.
Anyway, it'd be great if these stats made people realize that all the classes are very special-purpose, and that it's retarded to have more than two or three of each class on any given team, no matter the situation. But that won't happen. So oh well, at least they have pretty pictures.
I quite fail to see how a 35 hour workweek or 6 weeks of paid leave [...] are bad things.
By themselves, they aren't: everyone wants to work less, right? The problems are the effects they can have on the greater economy. In particular, in some countries, shorter work weeks and longer vacations are being used as a crutch to mask high unemployment. Say you have 15% unemployment because there are too few jobs, though there are plenty of sufficiently-skilled (i.e., employable) workers. What do you do? You decrease the work week by 12.5%. Now every company with 100 employees -- or 4000 man-hours per week -- only gets 3500 man-hours per week. Thus, to do the same amount of work, they must hire 14 or 15 more people. Extended nationwide, you end up with around 1% unemployment. Problem solved, right?
But hopefully you've already identified the problem: the company's employment costs just increased by 15%. That is either going to cut into the company's profit or wipe it out entirely. If the employees are all unionized or compensation is otherwise regulated, the company is going to find some other way to restore its profit margins. That could be through worse products, worse support, or the company shrinking by leaving less-profitable markets. All of those are bad things. (The company could just try to increase sales, but if it knew how to do that, it would've been doing it already.) And of course, if the employees aren't unionized, they'll all get screwed either through across-the-board pay cuts or through the new hires being grossly underpaid (pretty much a "McJob" at that point).
Note that both of these scenarios are very likely to result in decreased tax revenues. If the company sells a worse product and therefore gets fewer sales (or, depending on the tax code, makes less money), it pays less in taxes. If the employees get less on their paychecks, it's likely to move at least some of them into a lower tax bracket (assuming a progressive system), so even though the net salary paid out may be unchanged (15% salary cut, but 15% more people collecting that salary), tax revenues go down. That has an effect on the viability of the social programs which are so very important when your citizens aren't taking home much money (they can't afford not to use those programs).
This is all very simplified, of course. Most notably, I'm only talking about the possible negative consequences. It may be that working an hour less every day results in your employees being happier, less burned-out, and therefore much more productive. So I'm not saying that there aren't possible advantages. But most people don't seem to be aware of the risks, and I think that's a problem, hence they get the focus in this post.
But, I have to ask, (excluding those of you with Tablet PC's, because everything I've read indicates that Vista is pretty nifty on them) why?
My experience is that it Just Works. Everything is set up with a minimum of hassle and prompting, the defaults are sensible, and most of the eye candy has at least some redeeming value. (Like alt-tab shows you a small version of the windows, which is updated in realtime.) UAC is basically SEWindows, and it gets the same treatment as SELinux does (immediately disabled). But it's hard for me to fault Vista for that, since it is pretty much what every security expert was screaming for Microsoft to add.
Plus, Vista actually feels much more like it has a unified UI. I'm sure a MacOS user can tell you that the UI is more than just a window frame and menu bar: it's the "feel" of the whole thing that matters. Well, everything that comes with Vista (with a few aggravating exceptions, which fortunately I've never had to use more than once so far) has that "feel." If you've ever used IE7 on XP, you've probably noticed how utterly weird and confusing it is. Well, in Vista, it makes complete sense. (I still don't use it, of course, but I was tempted.)
I'm not a huge Vista booster or anything. The above makes me sound like I am, but you asked for reasons to use Vista, not reasons not to. But when I have to use the OS -- this computer is mainly a gaming rig -- I like it better than XP. And so long as I don't have to do any serious work, I much prefer it to KDE and GNOME. (For serious work, I need Unix. If I had to make do with screen and Alt+Fn, I would.)
Re:The probem with these types of books is that...
on
The Official Ubuntu Book
·
· Score: 2, Interesting
All I did was start the CUPS server, logged on to it, told it the printer's IP and model number, and it Just Worked(tm).
I think you and the GP are talking about different classes of printer, here, based on the fact that yours has an IP address. It's the cheapie inkjets that you get for free with a $500 computer that don't work right in Linux.
Pretty much any laser printer is going to Just Work(tm) in Linux, especially if you're sending it PCL or PS to its built-in, lpd-compatible print server over a TCP/IP network. Which is the way businesses usually do it, and that's why they work so well in Unix. (I bet you could plug a modern-day HP 4050 into a network of VAXen and they'd be able to print to it with no special configuration, too.)
You know, it's kind of weird, but the only people I know who like Vista are Unix people. The Windows people absolutely loathe it. I think it's because Vista is so different. XP, after all, was nothing more than a spitshine of 2000. All the changes in 2000, relative to 98, were under the hood. But MS is definitely trying to change the way you work with your computer in Vista. Personally, I really like it. It feels very much like KDE to me, though I don't know why. (Probably they are both copying Apple; I've never used OSX.)
I seriously considered replacing Kubuntu on my laptop with Vista, and I really like Kubuntu a lot.
The result is that if the motorcycle rider is uninsured we treat him at public expense -- and, if he rides without a helmet and is honest about it, he won't be able to get insurance. Therefore his riding affects all of us by costing us money.
The insurance part is a bit of a red herring, because in a libertopia, odds are good that nobody would have or want it. I know that if I had a choice, I wouldn't carry auto insurance at all (or I'd carry an extremely limited form that only covers things like personal injury suits). It'd save me about $2,200 a year. And I could always roll that money straight into a "personal insurance account" which makes interest.
And I'm not willing to concede that we, as a society, must give someone free healthcare when his life hangs in the balance. I'm not saying I necessarily disagree, mind you; I'm only saying that people tend to say "Of course we have to" and move on without offering any kind of a defense, as if no sensible person could disagree.
There is no solution to this problem that does not involve society as a whole somehow coercing the individual -- in other words, regulation.
I suppose it's just another form of coercion, but things like carbon offsets might work. Hey, libertarians are big fans of the free market. Whenever they're confronted with an unfamiliar problem, their solution is going to be "Can we somehow make a stock market out of it?" (Which is not, by the way, an unreasonable response. When you encounter a new problem, a good first approach is to try to make it into a problem you've already solved.)
Also, I think you'll find that allowing parents to hurt their kids in any way they want leads to some pretty gruesome consequences...
This is a straw man. Kids aren't property, they're people. If a parent beats the shit out of his kids, then he is obviously inflicting harm on another person, and therefore no libertarian in the world would object to the government getting involved in some capacity.
One not to unreasonable strategy is to set up SNMP traps on all your NICs.
That doesn't make much sense. If the NIC goes down or starts misbehaving, the chances of your NIC's SNMP traps arriving at their destination is effectively zero. You probably mean setting up traps on your switches with threshold traps on all the interfaces, the switch's CPU, CAM table size, etc. Which would be more useful. You could also use a syslog server, which is going to be considerably easier if you don't have a dedicated monitoring solution.
But they are all pretty standard these days, and your polling interval could be fairly long, like every 2 minutes.
You're not thinking of traps if you're talking about polling. Traps are initiated by the switch (or other device) and sent to your log monster. You can use SNMP polling of the sort that e.g. MRTG and OpenNMS do which, with appropriate thresholds, can get you most of the same benefits. But don't use it on Cisco hardware, not if you want your network to function, anyway. Their CPUs can't handle SNMP polling, not at the level you're talking about.
No alarms, but at least a quick heartbeat of your (conceivably very large) network. A similar system can be used to watch 30,000+ cable modems, without to much load on the snmp trap server.
I think you are underestimating exactly how much SNMP trap spam network devices send. You'll get a trap for the ambient temperature being too high. You'll get a trap if you send more than X frames per second ("threshold fired"), and another trap two seconds later when it drops below Y fps ("threshold rearmed"). You'll get at least four link traps whenever a box reboots (down for the reboot, up/down during POST, up when the OS boots; probably another up/down as the OS negotiates link speed and duplex), plus an STP-related trap for each link state change ("port 2/21 is FORWARDING"). You'll get traps when CDP randomly finds, or loses, some device somewhere on the network. You'll get an army of traps whenever you create, delete, or change a vlan. If you've got a layer 7 switch that does health checks, you'll get about ten traps every time one of your HA webservers takes more than 100ms to serve its test page, which happens about once per server per minute even when nothing is wrong.
And the best part is that because SNMP traps are UDP, they are the first thing to get thrown away when the shit hits the fan. So when a failing NIC starts jabbering and the poor switch's CPU goes to 100%, you'll never see a trap. All you'll see are a bunch of boxes on the same vlan going up and down for no apparent reason. You might get a fps threshold trap from some gear on your distribution or core layers, assuming it's sufficiently beefy to handle a panicked switch screaming ARPs at a gig a second and have some brains left over, but that's about it. More likely you won't have a clue that anything is wrong until the switch kicks and 40 boxes go down for five minutes.
Monitoring a network with tens of thousands of switch ports sucks hardcore, there's no way around it.
Unfortunately, SSH and Kerberos won't save you. Pretty much nothing will. In order for the script to authenticate itself as you without user intervention, the script needs your credentials. And if the script can read your credentials, then anyone who can run the script can read your credentials as well. In the case of a password hardcoded into the script, you can just cat the script; if you're using SSH, you can cat the private key; if you're using Kerberos, you can look at the keytab or cat the expect script which feeds your password to kinit.
You can do slightly better using MAC and such, but your time is better spent elsewhere. Like by making sure that riskyscript is bug-free, locking down the user account it's authenticating as so it can only perform the tasks it needs to, etc.
I don't know much about the inner workings of PSQL, but DB2 is highly parallel when it comes to I/O. This description of DB2's process model is pretty informative, though a bit overwhelming. In particular, you may want to look at some of the diagrams and the bit at the end about asynchronous page cleaners and I/O servers.
Slashdot Mirror
Yeah, I encountered that the other day. Built a VM, took a snapshot, did some stuff, reverted, did the same stuff. I was testing a procedure doc I was writing. Part of the procedure was creating an SSL cert, and I got an identical one on both attempts. That seems a little fishy to me; I would expect the certs to be (by the standards of cryptography) very similar, not identical. With that said, I didn't actually generate the cert myself, I ran a script (which I didn't write) to do it. The script might be using the same random seed or something. Or it could be a characteristic of moznss.
No shit. It might be worthwhile to use your desktop or some other hardware you control to seed your VM's PRNG with higher-quality entropy. That way, you should at least be able to avoid collisions with other VMs on the same hardware.
That's a great idea, but the problem is that the cost of digital reproduction is near enough zero as makes no difference. If you publish an e-book, and I buy a copy for $5, why would anyone else buy a copy when they could get one for free from me? Some people would do it out of habit. Others would do it because they feel it's the honest thing to do. But most people would not. I've got to imagine that it would be really hard to make a living this way.
You'd probably have to switch to a Kickstarter-like model. The prospective author uploads a high-level summary of what he wants to write. People who want to read it donate a couple bucks. The author then writes something and releases it for free. This would probably work, at least in a sense, but it'd be hard to fund longer works this way. You'd get a lot of short stories, novellas, and serials. I've got nothing against those formats, but I do like to have some diversity.
Philosophically, we're both in total agreement. I really only have a problem with how it would work (or not) in practice. I think a more realistic solution would be to have copyright, just like we do now, but with a drastically reduced term. Like, one year by default, up to a maximum of five years if you apply for an extension each year. If you can't break even on your copyrighted work in less than five years, you're never going to. If people are willing to wait for your copyright to expire rather than buying now, your work isn't important enough to deserve protection.
Yeah, the summary reads like word salad. Hell, the woman's name reads like word salad.
In this context, "internal" means "within the NSA," and "external" means "outside the NSA, but still within the federal government."
Hilariously topical malapropism.
The herbicide in question -- Roundup, aka glyphosate -- kills plants that aren't genetically modified to be resistant to it. If you plant a bunch of non-GM corn and then spray the whole thing with Roundup, you will kill everything, including the corn. So yeah, I can't imagine any reason a farmer would be doing that either.
It is if you can sell the duck for enough money to buy 400 shells.
Yes, it does need "all that bullshit." Booting from anything except an on-board hard disk controller on a PC BIOS is a hackjob. It's just an absolutely horrible clusterfuck. The fact that it ever works at all is a testament to the hard work put in over the past 20+ years by all the bootable expansion card makers.
I'm not trying to be a dick, but your comment really makes me think that you've never used anything except a desktop PC. In the server world, you always boot from an expansion card -- note that onboard NICs count as expansion cards in this context, because the BIOS can't boot from them directly; it has to pass control to the NIC's BIOS, which handles PXE -- at least once in the server's life to kickstart it. And there are a good number of situations where you never boot from a local hard disk. That's not just PXE. It also includes iSCSI and FC HBAs, ROMs or flash devices, RAID controllers, and probably a raft of things that I've simply never encountered.
I think that OpenBoot would've been a better choice than UEFI, personally. But I don't think any knowledgeable person can dispute the need for something better than the 1980s-era PC BIOS.
Ultimately, I think the compromise that we will get is that you will be able to resell used games, and you, the distributor, and the publisher will all get a cut. It's unfair for the publisher to get anything -- it doesn't right now, with physical media-only resales -- but you know they will fight and fight to prevent resales at all. The only way they'll ever agree to it is if they get something in return. Unfair though it might be, I don't see any solution that doesn't result in them getting a piece of the action.
The great thing is that digitally-distributed games are fungible. There's no difference between my used copy and your used copy, or even between a used copy and a new one. This means that you can handle them exactly the same way we handle stocks, bonds, and commodities, all of which are fungible too. It makes pricing largely automatic. Pricing could actually be made completely automatic, although it would work better if you at least let sellers put in bids manually.
I'd love to see an email app that complies with IT demands for a PIN lock, encryption, and remote wipe capabilities without turning those features on for the entire phone. I don't want to enter a goddamn PIN code just so I can play Zookeeper Battle. I don't need to encrypt the pictures of my wife and kid I have on my phone. And I don't think IT really cares if my Plants vs. Zombies achievements get stolen by a hacker.
I mean, I still wouldn't buy a Blackberry device. But that strikes me as an actual business-related value-add they could offer. All the other stuff people are talking about here -- "connect to an Exchange server" and "view Excel spreadsheets" seem to be the most common -- can already be done by every other phone in existence. Those aren't awesome things your BB does. Those are basic, entry-level features that any modern smartphone must have.
Anything with the sticky, setuid, or setgid bits set.
My car's approach is that pulling on the door handle twice from the inside will unlock (and open) the door. I wouldn't precisely call it intuitive, but it doesn't take long to figure out either. Actually, I think it is intuitive, it's just that people are so used to having to unlock the doors another way (push a button, flip a switch, pull a knob, whatever) that they don't expect it and therefore become confused.
BMW's rationale is that when you're in a panic situation -- on fire, sinking in a lake, etc. -- you're just going to pull on the handle until the door opens. It's a pretty decent idea. The problem, and it's a big one, is that it's probably electrical. So if the car loses power for some reason, you wouldn't be able to open the door. It could probably be done mechanically, though. For all I know it is.
I prefer the Futurama parties: Fingerlicans and Tastycrats.
But that demonstrates two (and possibly three) UI failures:
Of course, there is also a problem with the application putting root-owned crap in the user's home directory. That's usually a design error with "legacy" apps that reinvent the configuration-storing wheel. (You should be using the APIs provided by GNOME, KDE, or whatever else.)
According to WP, DOS 2.0 introduced directories. The reason for using the forward slash to indicate options is probably that DCL from (Open)VMS does it that way. Note that, just like in DCL, the forward slash is a special character to the command interpreter, which will automatically start a new argument to the invoked program or function. In other words, arguments will be split by the interpreter at forward slashes.
Of course, this doesn't explain why they used backslashes. If they were modeling DOS after VMS, they'd have used dollar signs or colons or some other craziness. It's almost like they hired a bunch of VMS junkies, settled on forward slashes for switches, fired all the VMS wizards and replaced them with Unix gurus, then introduced directories.
No, but presumably there will be a way to describe that change. I mean, it's quite possible we're already doing it without really being aware. And that's kind of the problem: we're inside the universe, so we have no objective view of it. We can't see it changing, because change is by definition relative to something else and we have nothing else for comparison.
My personal crazy belief is that we "force" the universe into sense. We don't really change it, we simply change our perceptions until the universe seems perfectly logical and natural. If the universe were to change suddenly in some unexpected and strange way, then we would simply change our perceptions of it until it made sense again. It's kind of like how insane people will build perfectly consistent internal worldviews which are utterly mad from the perspective of others. Well, not kind of like, exactly like. It's also doublethink, of course, but humans do that all the time anyway.
It's not entirely crazy, though. Evolution would play a part in it. Why does the universe sometimes seem a little too orderly, a little too logical? Because, of course, we have evolved to live in the universe. We wouldn't be viable as a species if the universe were unpredictable and changing all the time. So whatever little tweaks in our DNA were required in order for us to make sense of this chaotic place, we got. We are, in essence, wired at a very fundamental level to think the same way as the universe. So naturally (literally) it all can sometimes seem so clear and... well, planned.
(Yes, I was being vaguely ironic at the end there. Yes, I realize it sounds like I'm talking about God, just using the word "universe" instead. No, I'm not actually saying that, though I believe that if there is such an entity, that's the shape it'd have to take.)
I think it was more a commentary on the relative popularity of the classes than their strengths and weaknesses. For example, if you look at the full stats from Valve, you'll see that scouts are the most popular class, but also one of the least effective (fourth-worst in points gained, second-worst in kills earned). Looking at it from the other side, heavies are probably the most effective class overall, but they're the fourth-least popular class. Unsurprisingly to anyone who's ever played TF2, medics are the least popular class by a wide margin -- but they are also the entire reason that heavies are so good, and that's reflected in their scores (almost three times as many assists per hour as the next-highest class, and it's enough to make them get more points per hour than demos and engineers, and almost scouts!).
My only gripe about TF2 has nothing to do with the game, and everything to do with the players. I always end up being a medic because nobody else will do it. I don't get it. Medic is by far the easiest class to play. You'd expect the noobs to gravitate to it, just like they do in CS to the AWP (the easiest gun in the game, since it's the only one that shoots straight). Yet they choose probably the hardest class -- scout -- for some reason.
Anyway, it'd be great if these stats made people realize that all the classes are very special-purpose, and that it's retarded to have more than two or three of each class on any given team, no matter the situation. But that won't happen. So oh well, at least they have pretty pictures.
By themselves, they aren't: everyone wants to work less, right? The problems are the effects they can have on the greater economy. In particular, in some countries, shorter work weeks and longer vacations are being used as a crutch to mask high unemployment. Say you have 15% unemployment because there are too few jobs, though there are plenty of sufficiently-skilled (i.e., employable) workers. What do you do? You decrease the work week by 12.5%. Now every company with 100 employees -- or 4000 man-hours per week -- only gets 3500 man-hours per week. Thus, to do the same amount of work, they must hire 14 or 15 more people. Extended nationwide, you end up with around 1% unemployment. Problem solved, right?
But hopefully you've already identified the problem: the company's employment costs just increased by 15%. That is either going to cut into the company's profit or wipe it out entirely. If the employees are all unionized or compensation is otherwise regulated, the company is going to find some other way to restore its profit margins. That could be through worse products, worse support, or the company shrinking by leaving less-profitable markets. All of those are bad things. (The company could just try to increase sales, but if it knew how to do that, it would've been doing it already.) And of course, if the employees aren't unionized, they'll all get screwed either through across-the-board pay cuts or through the new hires being grossly underpaid (pretty much a "McJob" at that point).
Note that both of these scenarios are very likely to result in decreased tax revenues. If the company sells a worse product and therefore gets fewer sales (or, depending on the tax code, makes less money), it pays less in taxes. If the employees get less on their paychecks, it's likely to move at least some of them into a lower tax bracket (assuming a progressive system), so even though the net salary paid out may be unchanged (15% salary cut, but 15% more people collecting that salary), tax revenues go down. That has an effect on the viability of the social programs which are so very important when your citizens aren't taking home much money (they can't afford not to use those programs).
This is all very simplified, of course. Most notably, I'm only talking about the possible negative consequences. It may be that working an hour less every day results in your employees being happier, less burned-out, and therefore much more productive. So I'm not saying that there aren't possible advantages. But most people don't seem to be aware of the risks, and I think that's a problem, hence they get the focus in this post.
My experience is that it Just Works. Everything is set up with a minimum of hassle and prompting, the defaults are sensible, and most of the eye candy has at least some redeeming value. (Like alt-tab shows you a small version of the windows, which is updated in realtime.) UAC is basically SEWindows, and it gets the same treatment as SELinux does (immediately disabled). But it's hard for me to fault Vista for that, since it is pretty much what every security expert was screaming for Microsoft to add.
Plus, Vista actually feels much more like it has a unified UI. I'm sure a MacOS user can tell you that the UI is more than just a window frame and menu bar: it's the "feel" of the whole thing that matters. Well, everything that comes with Vista (with a few aggravating exceptions, which fortunately I've never had to use more than once so far) has that "feel." If you've ever used IE7 on XP, you've probably noticed how utterly weird and confusing it is. Well, in Vista, it makes complete sense. (I still don't use it, of course, but I was tempted.)
I'm not a huge Vista booster or anything. The above makes me sound like I am, but you asked for reasons to use Vista, not reasons not to. But when I have to use the OS -- this computer is mainly a gaming rig -- I like it better than XP. And so long as I don't have to do any serious work, I much prefer it to KDE and GNOME. (For serious work, I need Unix. If I had to make do with screen and Alt+Fn, I would.)
I think you and the GP are talking about different classes of printer, here, based on the fact that yours has an IP address. It's the cheapie inkjets that you get for free with a $500 computer that don't work right in Linux.
Pretty much any laser printer is going to Just Work(tm) in Linux, especially if you're sending it PCL or PS to its built-in, lpd-compatible print server over a TCP/IP network. Which is the way businesses usually do it, and that's why they work so well in Unix. (I bet you could plug a modern-day HP 4050 into a network of VAXen and they'd be able to print to it with no special configuration, too.)
You know, it's kind of weird, but the only people I know who like Vista are Unix people. The Windows people absolutely loathe it. I think it's because Vista is so different. XP, after all, was nothing more than a spitshine of 2000. All the changes in 2000, relative to 98, were under the hood. But MS is definitely trying to change the way you work with your computer in Vista. Personally, I really like it. It feels very much like KDE to me, though I don't know why. (Probably they are both copying Apple; I've never used OSX.)
I seriously considered replacing Kubuntu on my laptop with Vista, and I really like Kubuntu a lot.
The insurance part is a bit of a red herring, because in a libertopia, odds are good that nobody would have or want it. I know that if I had a choice, I wouldn't carry auto insurance at all (or I'd carry an extremely limited form that only covers things like personal injury suits). It'd save me about $2,200 a year. And I could always roll that money straight into a "personal insurance account" which makes interest.
And I'm not willing to concede that we, as a society, must give someone free healthcare when his life hangs in the balance. I'm not saying I necessarily disagree, mind you; I'm only saying that people tend to say "Of course we have to" and move on without offering any kind of a defense, as if no sensible person could disagree.
I suppose it's just another form of coercion, but things like carbon offsets might work. Hey, libertarians are big fans of the free market. Whenever they're confronted with an unfamiliar problem, their solution is going to be "Can we somehow make a stock market out of it?" (Which is not, by the way, an unreasonable response. When you encounter a new problem, a good first approach is to try to make it into a problem you've already solved.)
This is a straw man. Kids aren't property, they're people. If a parent beats the shit out of his kids, then he is obviously inflicting harm on another person, and therefore no libertarian in the world would object to the government getting involved in some capacity.
That doesn't make much sense. If the NIC goes down or starts misbehaving, the chances of your NIC's SNMP traps arriving at their destination is effectively zero. You probably mean setting up traps on your switches with threshold traps on all the interfaces, the switch's CPU, CAM table size, etc. Which would be more useful. You could also use a syslog server, which is going to be considerably easier if you don't have a dedicated monitoring solution.
You're not thinking of traps if you're talking about polling. Traps are initiated by the switch (or other device) and sent to your log monster. You can use SNMP polling of the sort that e.g. MRTG and OpenNMS do which, with appropriate thresholds, can get you most of the same benefits. But don't use it on Cisco hardware, not if you want your network to function, anyway. Their CPUs can't handle SNMP polling, not at the level you're talking about.
I think you are underestimating exactly how much SNMP trap spam network devices send. You'll get a trap for the ambient temperature being too high. You'll get a trap if you send more than X frames per second ("threshold fired"), and another trap two seconds later when it drops below Y fps ("threshold rearmed"). You'll get at least four link traps whenever a box reboots (down for the reboot, up/down during POST, up when the OS boots; probably another up/down as the OS negotiates link speed and duplex), plus an STP-related trap for each link state change ("port 2/21 is FORWARDING"). You'll get traps when CDP randomly finds, or loses, some device somewhere on the network. You'll get an army of traps whenever you create, delete, or change a vlan. If you've got a layer 7 switch that does health checks, you'll get about ten traps every time one of your HA webservers takes more than 100ms to serve its test page, which happens about once per server per minute even when nothing is wrong.
And the best part is that because SNMP traps are UDP, they are the first thing to get thrown away when the shit hits the fan. So when a failing NIC starts jabbering and the poor switch's CPU goes to 100%, you'll never see a trap. All you'll see are a bunch of boxes on the same vlan going up and down for no apparent reason. You might get a fps threshold trap from some gear on your distribution or core layers, assuming it's sufficiently beefy to handle a panicked switch screaming ARPs at a gig a second and have some brains left over, but that's about it. More likely you won't have a clue that anything is wrong until the switch kicks and 40 boxes go down for five minutes.
Monitoring a network with tens of thousands of switch ports sucks hardcore, there's no way around it.
Unfortunately, SSH and Kerberos won't save you. Pretty much nothing will. In order for the script to authenticate itself as you without user intervention, the script needs your credentials. And if the script can read your credentials, then anyone who can run the script can read your credentials as well. In the case of a password hardcoded into the script, you can just cat the script; if you're using SSH, you can cat the private key; if you're using Kerberos, you can look at the keytab or cat the expect script which feeds your password to kinit.
The typical way around this is e.g.:
You can do slightly better using MAC and such, but your time is better spent elsewhere. Like by making sure that riskyscript is bug-free, locking down the user account it's authenticating as so it can only perform the tasks it needs to, etc.
I don't know much about the inner workings of PSQL, but DB2 is highly parallel when it comes to I/O. This description of DB2's process model is pretty informative, though a bit overwhelming. In particular, you may want to look at some of the diagrams and the bit at the end about asynchronous page cleaners and I/O servers.