Maybe I'm the only one, but I used to like the record clubs.
I feel a little dirty for saying that now; but this was before I realized that Sony/BMG/Columbia Universal are just various arms of the Great Satan and all that.
I'd do one record club stint every year or so. Basically I'd start making a list of all the albums I wanted, mostly by listening to the radio, or based on friends who had more money than I did and could afford to buy the new releases. Then I'd wait for one of the music clubs to send one of their deals (in later years, one of them had a sweet one, something like '15 CDs for $10 with nothing more to buy ever!') and then go down my list and get all the CDs they had that I wanted. Then I'd cancel it, and spend the next few months / year listening to my new CDs and adding stuff to my list.
Obviously, I wasn't a huge consumer of music. I'm still not, but it let me build a pretty decent CD collection off of my lawn-mowing/summer-job/beer-bottle-return money, which I couldn't have done otherwise at the time. (Well, maybe I could have done almost as well at used-CD/record stores.)
I bring this all up because it's about the same way that I use Netflix today. I go on again and off again with Netflix. I'll basically make up a list, usually starting as a mental one and then progressing to a written one when it gets too long, of all the movies I want to see. Eventually I'll subscribe to Netflix, and over the course of a few months work down the list. When I either exhaust the movies I want to see, or just get bored with watching a movie or recorded TV show every night / every few nights, I'll cancel it.
Right now I'm on my third Netflix iteration (I gave up on the music clubs a while back; I wonder if they're still around?) and about to cancel it, since my interest is starting to peter out.
Whether you can make these systems work for you, or whether you end up being the proverbial sucker that keeps the house in business, depends on your level of patience. If you can bear to not buy anthing for a few months and keep a list of stuff you want to see/hear, and then watch it all at once (or, I suppose, rip it... but that's A Bad Thing to do, right kids?), you can really save a lot of money and get a lot of cool entertainment for cheap. But if you either don't use it much and/or then don't cancel, then you're just making some executive's boat payments for him.
That's kind of how the closed-source patch process works.
When a vulnerability becomes known, you patch it; if the result of the patch is that you create a new vulnerability somewhere in exchange, this is still acceptable, since you're trading a known vuln for an unknown one. When somebody finds the new hole, you repeat the process, ad infinium. Nobody does enough testing to verify everything, and particularly when you're in a rush to release a fix for a security exploit there's even less time for regression testing.
In an open development environment, it's tougher to fix something if you create a new hole in the process, since the holes are more immediately visible. While this might concievably mean that severe holes take longer to fix (although in practice I don't think they do), because you have to find a fix that doesn't create new holes, the overall quality ought to get higher over time, instead of just staying basically constant. In effect, the open development model puts far more emphasis on code review and regression tests than would ever be practical or economically feasible for most commercial closed-source development efforts.
Marketing deadlines always trumps everything else, except for OpenBSD and maybe Linux kernels. Curiously, both have dominant but benevolent personalities in charge......
I had never heard of such a thing before (actually, initially I thought you were just punning on Windows + 'shattering', har har).
It would seem that Vista allegedly fixes the design flaw that allows for the attack, by not running system services in the same session as the user. At least, that seems to be what the Wikipedia article on the topic is suggesting.
The key to shatter attacks is that Windows allows processes running in the same session to pass messages between each other, the result of which is that via code injection, any process can escalate up to the level of the highest process also running in its session. MS is quoted in the article as saying "[This is not] a flaw in Windows. In reality, the flaw lies in the specific, highly privileged service. By design, all services within the interactive desktop are peers, and can levy requests upon each other. As a result, all services in the interactive desktop effectively have privileges commensurate with the most highly privileged service there." (Which is amusingly doublespeak-ish; they're saying "this isn't a design flaw, we designed it that way!")
This blog post by a member of the IE7 team would confirm that they've at least tried to address this in Vista (but of course that's what you'd expect them to say). It says: "User Interface Privilege Isolation (UIPI) blocks lower-integrity from accessing higher-integrity processes. For example, a lower-integrity process cannot send window messages or hook or attach to higher priority processes This helps protect against "shatter attacks." A shatter attack is when one process tries to elevate privileges by injecting code into another process using windows messages."
Yet another nice legacy "feature" from the single-user-OS days.
The problem with SGI is that they don't really have any compelling products anymore. They have some Linux-based HPC stuff, but I think they've lost the early lead they might have had (as a result of their clustering experience for graphics stuff) in that market to IBM. Then they have some Itanium workstations, which are hideously overpriced, and aside from being Itanium seem to pretty much be a run-of-the-mill workstation in a neat case. (About the only feature they have that you can't get on something from Sun/HP/IBM is a binary compatibility layer for running IRIX applications side-by-side with Linux ones.) And then of course they have some IRIX workstations, for the few people who still have a business reason for staying with IRIX.
But most of the people still running IRIX are doing so because they have legacy applications that they need to use, which assumedly already runs on their existing hardware... meaning they're not going to be purchasing a lot of new gear.
SGI is rapidly running of of stuff to sell. What they do make looks really neat (gotta love purple), and I'd love to have one under my desk, but it's tough to come up with a business case for the premium it seems like they have to charge in order to stay afloat.
As much as I hate to say it, being someone who's drooled over SGI gear for years, I think they need to exit the hardware business. Or perhaps license the SGI hardware brand out to someone else, to use as their high-end workstation brand. Then pare the company back and concentrate on software for the very high-end visualization markets, and perhaps offer consulting services for people converting from IRIX to Linux.
It seems like they tried to play IRIX for far too long after the writing was on the wall, and the gamble with Itanium didn't help either. Running a single-vendor OS on what's rapidly becoming a single-vendor hardware platform isn't something that many people are going to be interested in.
Just out of curiosity (and since I'm not a Windows user, except for a copy I have installed on a virtual machine to play with), is there any way to avoid getting WGA-ed if you turn on Automatic Updates?
I just turned Auto-Updates off completely, figuring I can just roll the VM back if it gets infected with something, but I'm curious as to whether the user has any control over WGA's installation, or if it just gets slipped in by MS the second you allow automatic installation of updates.
Can you get just the security patches, but refuse to install everything else? Or is WGA considered a "security" patch? (Which would be suitably ironic -- it's 'security' all right, just not for the user.)
I know you're joking (well, maybe), but I often think that the Slashdot crowd fails to appreciate how many people there are in the world -- very smart people, in fact, in many cases -- who are more than willing to take the "dirty" jobs.
Particularly if they're interesting dirty jobs.
The fact that what you're doing can be used to kill people fades away into relative unimportance pretty quickly, if there's a cool technical challenge to be solved, and the salary is right, and the people you get to work with are similarly goal-oriented.
There are a lot of people in the world who spend their days thinking of new and interesting ways to kill others, and I'm willing to bet that most of them probably don't lose sleep at night over it. The human mind has an amazing ability to rationalize -- if not flat-out ignore -- almost anything, and social mores regarding the value of others' lives are no exception.
The quality of AllofMP3.com is a lot better than you can get off of P2P, at least reliably.
There's no fucking around with downloading an album, only to find out that some idiot ripped it at 128kb, which I think sounds worse than a bag full of angry cats. Or you find out the file is fake, or loaded with spyware, or that you have to open a bunch of ports through your firewall in order to get the P2P app to work in the first place, etc.
With AllofMP3, you click on the album, choose your quality level (all the way up to uncompressed 44.1kHz, in some cases) and you get your music. No messing around.
Apple has always given the impression that they aren't interested in expending a whole lot of effort on DRM, and pretty much do whatever they think the bare minimum that's necessary to pass the studio's "sniff test."
Their attitude seems to be 'release whatever we can squeeze by the studios, and then if something becomes a major problem, we'll change it.' Hence the original versions of iTunes had some neat remote-music-sharing features, but then when they became major sources of piracy and the studios started to complain (assumedly -- I can only imagine the irate phone calls from Sony/Warner/BMG), they got removed.
Obviously as long as Apple has to maintain a relationship with the content monopolies, we probably won't see much in the way of a relaxation of the rules, but it's never seemed like Apple was really the one pushing the restrictions. If they were, their products would look a lot different (more like the early Sony attempts at running a music store).
I'm not being a complete Apple apologist -- they've obviously crippled their products in order to do business with the Sonys of the world, so at the very least they're guilty of some level of collaboration, but if they thought the same way as Sony does on a fundamental level, we'd never have seen the abilities that iTunes has now or had initially.
Slightly OT: does anyone know whether the iPod Video imposes Macrovision on the analog composite video output? I'm guessing that it doesn't, meaning that if you really wanted to un-DRM something that you bought, it would be pretty simple to loop the output of the iPod back into the analog input of a ADC (like an EyeTV or similar) and re-dig the video. Like burning music to CD and back there's an obvious quality loss, which personally I wouldn't find acceptable, but people who happily watch shitty videos produced by somebody in a theater with a camcorder probably wouldn't mind.
I live in a city, which means the post office does not collect outgoing mail, so Netflix is inconvenient
Huh?
What do you mean, it doesn't collect outgoing mail?
I live in a city too, and you can't go two blocks without tripping over a USPS "blue box." Plus, every apartment building that I've ever been in has an outgoing mailbox, right next to the incoming boxes (which are actually superior to the way you do outgoing mail in a rural area -- where you put it in your regular box and put the flag up -- since it can't be stolen).
I'd say that Netflix is much more convenient/practical for people in urban areas than in rural ones, since the delivery turnaround times are usually faster, and in many cases you can send the discs back faster. When I lived in a rural area, I'd stick them in my mailbox and wait for the carrier to pick them up the next morning; now that I live in a city, I put them in the USPS box on the corner, and they go out that afternoon (pickup at 4:30 pm), effectively cutting a day off the mail-in time. When I'm feeling lazy, I just put them in the box on my house and they get picked up the next day.
I can't think of any situation where you can receive mail, but not send it back out. If you use lockable boxes, there should be an outgoing-slot or receptacle nearby. (I think this is required by the DMM.) If you use a box affixed to your house without a flag, then you put your outgoing stuff in it and the carrier will take it out before putting the incoming mail in, and if you have a rural streetside box, then you put it in there and set the flag up.
Any carrier delivering mail will also accept it (assuming it's of "nominal amount" -- you can't hand them a 20 lb package and expect them to carry it around the rest of their route), so if you have mail delivery, you should have a way of sending it back out.
In all seriousness, I know someone who's used themselves as an antenna. It's not particularly hard to do if you have a good transmatch/antenna tuner. That said, I definitely wouldn't recommend doing it. (Not sure what the health effects would be of ultra-QRP down in the HF bands, which is what I think the guy did; only a few hundred mW probably...still, I'm not going to try, thanks.)
When it comes to "making an antenna out of x," where x is virtually any object that's even halfway conductive, someone somewhere has probably tried to push RF through it at some point in the past.
If you're interested in a significantly safer version of the same principle, which doesn't involve licking your finger and touching things which you shouldn't be touching, there is a whole community of people who build salt-water antennas: http://www.wireservices.com/n9zrt/ila/ila.html
The GP -- the skydiver -- is paying for the energy he's using when he goes skydiving. He pays for the charter of the plane (probably splitting it with the other people who are going, and also paying for a lot of other stuff, like the pilot, etc.). But he paid for the energy that it's taking to get him up there so he can enjoy his fun floating down.
Likewise, the person driving the Suburban around town to get their groceries is paying for it every time they fill up its tanks at the pump. Maybe you think it's stupid and wasteful, but apparently they disagree -- and they're spending their money on the gas they're burning to prove it.
It's not as if people don't think about the cost of energy -- they do; it's just that their cost/benefit analysis comes out differently than if you did the same thing. The guy going skydiving is saying "it's worth x dollars and y liters of aviation-grade kerosene so I can go parachuting," and the woman with the Suburban is saying "it's worth z dollars and n gallons of gasoline for me to drive around in a car that's bigger than everyone else's."
They're not taking anything from you in doing this -- you could have had the same amount of gas that they did (it's not like it's rationed), if you had wanted to pay for it. When the supply starts to dry up, and the price increases, doubtless people will reconsider whether their gas-intensive recreational activities are worth the cost anymore, or whether their ginormous vehicles are really practical. But for right now, those people are voting in the most important way they can -- with their wallets -- and saying that it is worth it.
Now you could argue that the price of gas is artificially inexpensive, compared to what it should be if all the negative externalities associated with its use were taken into account. I might even agree with you there. (Although I don't think that just increasing taxes on it, whose revenue flows into general funds and is squandered, instead of actually being spent on those externalities, is productive.)
You could also argue, and here I would agree, that the companies and other entities regulating the price of petroleum products today aren't doing a very good job taking into account the future demand for their product. That is to say, they're selling too much of it too quickly right now, in order to reap short-term gains, when instead they could get a lot more for it by extracting it more slowly and selling it at a higher price to those people willing to pay. (Aviation, for instance, is impractical without fossil fuels -- very few other things have the required energy density.) However, this is a wholly separate argument from what people should be able to do with that gas, provided they're buying it at the market rate along with everyone else.
Even when gas is $15 a gallon, there will still be some people who think it's worthwhile to drive an inefficiently large car, or own gas-powered personal watercraft, or go skydiving -- and that's their decision. They have just as much a right to do that with the gas that they buy, as you do, to go wherever you want on your scooter and its tankful, which you bought. As long as both of you are paying the same price for the same product, meaning that you both get to perform the cost/benefit analysis, it's the height of arrogance to pass judgement on others' hobbies.
It would seem to me that one of the strengths of the COTS solutions are that they have fairly slick integrated interfaces for managing access.
If you roll your own, you might well have to set up Samba/CIFS/Netatalk all separately, which could easily become a huge pain. If you want a new share, you'd have to add it manually to all three, and deal with their varying authentication schemes.
I did some Googling around for OSes specifically designed for roll-your-own NAS boxes (which it seems must exist), and came up with some stuff. One of the neatest projects looks like it has died, which is sad: Darma NAS OS. It seemed to be Linux-based and had a Java web-based management GUI, used the usual SMB/NFS/AppleShare, and supported ACLs and some other neat management stuff.
I'm curious what people who've gone the DIY route are using to ease the management hassle that I could easily see a SAN becoming if it's OS is just straight Linux.
Just say no to battery packs.
on
More Wii-mote Info
·
· Score: 3, Informative
I really hate having a proprietary battery cartridge when a few generic rechargeable AAs could have done the job just as well, and let me not pay the hefty premium for the few cents of cheap plastic that they used to bundle them together with. Plus, with standard-size batteries, you have the option of using regular alkalines in a pinch if you really want to -- if you use a proprietary pack and it runs out, you're SOL until it recharges.
The only excuses for using proprietary batteries at all are if the form factor is such that a standard-shaped (AA/LR6 NiMH) won't fit, or the increased energy density of a Li-ion is required.
The best combination is to use standard-sized, replaceable cells and then have an external charging port so that the batteries can be charged without removing them from the device. Unfortunately, few manufacturers of consumer products do this because of the safety features you need to put on the charger in order to keep it from trying to charge the alkalines that people will inevitably put in there, even if you warn them not to.
This is like somebody going around selling paper-mache deadbolts and telling you about all the horrible things that can happen to your home if you don't buy one. There's an obvious level of dishonesty in selling something and calling it protection (particularly since they go so far as to call it "encryption") when it's fairly trivial to break, and won't protect you against anyone who wants to steal your stuff.
The only thing worse than the criminals themselves are the charlatans who try to foist snake-oil "protection" schemes on unwitting consumers and companies.
I'm going to have to disagree with you there. I know a number of companies that are running IBM z/Series mainframes, in part because they are binary-compatible with programs written for the System/370 (not sure if they're compatible with the S/360, they may be). Heck, IBM designs some of their hardware specifically in order to make it backwards-compatible to systems that there probably aren't any extant examples of, because the software from them still works fine. (EBCDIC page translation hardware, etc.) I doubt they're the only ones.
I think you're vastly underappreciating the lifespan of production systems. There is a lot of old green-screen COBOL stuff out there, perhaps not running on the original hardware, but running in various layers of emulation or compatibility modes. Why? Because it still works. Because the fundamental problems that it solves haven't changed that much, and frankly don't change very often.
If there's a lesson programmers should take away from the past 40+ years of commercial software development, it's that software often vastly outlives its original estimated lifespan. (In some cases, maybe even outliving the programmers themselves.) The current post-bubble slowdown in commercial upgrade and adoption cycles, and increased skepticism of IT purchasing, will probably only emphasize this, and anyone starting a project today should plan on a longer lifecycle than they might have anytime before in the past 20 years.
The fact that programs like tar and man have been constantly updated and maintained over the past few decades doesn't really help your case much; you'd do better to look at the syntax of those programs and see how little it's changed in the interim. Tar still has support for syntax ("tar xvf...") which is horribly obsolete, because removing it would break legacy scripts and applications that people still depend on.
Building custom, special-purpose software for a 3-to-5-year lifecycle is totally inappropriate, and history has shown that it's generally not the way the world works. If anything, someone coding a custom enterprise ERP system would be better off keeping in mind "how is someone in 30 years, who only knows what we bothered to write down, going to understand what I was thinking when I wrote this?" Because chances are, if you're doing your job right, and the people planning the project were doing their jobs right and found the right 'fundamental problems' to solve, there's no reason why the software itself may not still be in use three decades hence.
In any large company, there is a lot of information floating around that you are probably better off not having access to.
While it doesn't make sense to have every secretary and general low-level peon be able to encrypt stuff in such a way that nobody can ever recover them, I would not want to have automatic access to extremely sensitive high-level stuff stored on the executive's systems. Why? Because if somehow it gets leaked, and you have the root password, you have zero plausible deniability. In other words, you become quite easy to scapegoat.
If you work someplace where there isn't any internal backstabbing, and nobody above you would ever consider hanging their poor sysadmin out to dry in order to save their own pillowtalking ass, then great. Let me know where to send my resume.
Generally speaking, while I would want to be sure that I had admin/override rights to all the people below me in a chain of command, I wouldn't want to have those rights to people above me in the chain of command. Not because I'd find the idea of reading my boss' email particularly tempting, but because when something Bad Happens, I want to be able to say with absolute candor, not only didn't I do anything, but I couldn't possibly have done anything.
It's like having the keys to a file cabinet which contains information way above your security clearance level. I wouldn't want to have them, because I don't want to be the guy in the hot seat when somebody way above my pay grade fucks up and decides to find someone expendable to take the blame.
Let the executives have their personal encrypted folders, with a nice big warning sign that says "If you forget your password, NOBODY ELSE WILL BE ABLE TO ACCESS THIS." If they forget their passwords, then it's their problem, or if they maliciously encrypt things as they're tendering their resignation, then it's Legal's problem. The last thing I'd want to do is make it my problem.
I was surprised and pleased to see Andy Ihnatko on there. I guess I'd missed him for a few years -- ever since he stopped doing the second-to-last-page columns for MacWorld (and before that, if memory serves, MacUser), I'd been wondering whatever happened to him. There was a considerable period during what I call the "dark ages" of the Mac when the only reason I kept up my subscription was for his column.
After all, props are still in order if only for being the inventor of "Web That Smut," possibly the only good thing to ever happen as the result of the Communications Decency Act. (The original column is here, archived via the Wayback Machine, but I'm not sure if Slashdot is going to mangle the link.)
And of course there's also the millenial version, Web That DeCSS!
That's a great anecdote, and I don't think that you can hit that point hard enough.
If somebody came to you and said "hey, I've got this great new way to build a bridge! Instead of making up plans, we'll just start building it! We'll build it out of popsicle sticks first, and then we'll go in and add some steel beams, and toss some pavement on top of that," you'd say they were insane. Nobody does stuff like that in the real world -- yet that's exactly what a lot of poorly-managed 'agile' software projects are doing. They're getting short-term prototyping gains but at the cost of maintainability and probably stability as well.
Rather than figuring anything out ahead of time -- actually answering the hard questions like "what do we want this software to do and how do we want to do it?" they just start making something. It's like just giving some steelworkers a pile of rebar on either side of the river and telling them to build towards the center and figure the details out later.
I think one of the biggest problems in software development, and it's really endemic, is an underappreciation of the pre-development work: requirements analysis, specification development, even simple stuff like the clear division of job roles and responsibilities. If you get that stuff done, the actual coding ought to be an academic exercise, not a seat-of-the-pants experiment.
Part of the problem lies with managers who don't understand software, and just take any opportunity to compress schedules and make themselves look better, and another problem is with "programmer culture," where people think the ideal way to solve a complicated problem is just to put a half-dozen developers in a room for a weekend with a few gallons of Mountain Dew, an Amex card, and the number of the nearest Domino's Pizza. (Although to be fair, this attitude seems to be less common among developers who have SOs/families, or are used to 40-hour workweeks.)
While concentrating on "getting it out the door" may solve the problem in the short run, it's almost certainly not going to give you neat, easily-maintainable, well-documented code. And when you're looking at the long-term maintainance costs, it sometimes can be better to not have anything at all, than to have a lot of spaghetti code that somebody is just going to have to rewrite down the road, when they can't figure it all out.
Maybe I'm the only one, but I used to like the record clubs.
... but that's A Bad Thing to do, right kids?), you can really save a lot of money and get a lot of cool entertainment for cheap. But if you either don't use it much and/or then don't cancel, then you're just making some executive's boat payments for him.
I feel a little dirty for saying that now; but this was before I realized that Sony/BMG/Columbia Universal are just various arms of the Great Satan and all that.
I'd do one record club stint every year or so. Basically I'd start making a list of all the albums I wanted, mostly by listening to the radio, or based on friends who had more money than I did and could afford to buy the new releases. Then I'd wait for one of the music clubs to send one of their deals (in later years, one of them had a sweet one, something like '15 CDs for $10 with nothing more to buy ever!') and then go down my list and get all the CDs they had that I wanted. Then I'd cancel it, and spend the next few months / year listening to my new CDs and adding stuff to my list.
Obviously, I wasn't a huge consumer of music. I'm still not, but it let me build a pretty decent CD collection off of my lawn-mowing/summer-job/beer-bottle-return money, which I couldn't have done otherwise at the time. (Well, maybe I could have done almost as well at used-CD/record stores.)
I bring this all up because it's about the same way that I use Netflix today. I go on again and off again with Netflix. I'll basically make up a list, usually starting as a mental one and then progressing to a written one when it gets too long, of all the movies I want to see. Eventually I'll subscribe to Netflix, and over the course of a few months work down the list. When I either exhaust the movies I want to see, or just get bored with watching a movie or recorded TV show every night / every few nights, I'll cancel it.
Right now I'm on my third Netflix iteration (I gave up on the music clubs a while back; I wonder if they're still around?) and about to cancel it, since my interest is starting to peter out.
Whether you can make these systems work for you, or whether you end up being the proverbial sucker that keeps the house in business, depends on your level of patience. If you can bear to not buy anthing for a few months and keep a list of stuff you want to see/hear, and then watch it all at once (or, I suppose, rip it
That's kind of how the closed-source patch process works.
When a vulnerability becomes known, you patch it; if the result of the patch is that you create a new vulnerability somewhere in exchange, this is still acceptable, since you're trading a known vuln for an unknown one. When somebody finds the new hole, you repeat the process, ad infinium. Nobody does enough testing to verify everything, and particularly when you're in a rush to release a fix for a security exploit there's even less time for regression testing.
In an open development environment, it's tougher to fix something if you create a new hole in the process, since the holes are more immediately visible. While this might concievably mean that severe holes take longer to fix (although in practice I don't think they do), because you have to find a fix that doesn't create new holes, the overall quality ought to get higher over time, instead of just staying basically constant. In effect, the open development model puts far more emphasis on code review and regression tests than would ever be practical or economically feasible for most commercial closed-source development efforts.
Marketing deadlines always trumps everything else, except for OpenBSD and maybe Linux kernels. Curiously, both have dominant but benevolent personalities in charge......
Also, both of them lack marketing departments.
I had never heard of such a thing before (actually, initially I thought you were just punning on Windows + 'shattering', har har).
It would seem that Vista allegedly fixes the design flaw that allows for the attack, by not running system services in the same session as the user. At least, that seems to be what the Wikipedia article on the topic is suggesting.
The key to shatter attacks is that Windows allows processes running in the same session to pass messages between each other, the result of which is that via code injection, any process can escalate up to the level of the highest process also running in its session. MS is quoted in the article as saying "[This is not] a flaw in Windows. In reality, the flaw lies in the specific, highly privileged service. By design, all services within the interactive desktop are peers, and can levy requests upon each other. As a result, all services in the interactive desktop effectively have privileges commensurate with the most highly privileged service there." (Which is amusingly doublespeak-ish; they're saying "this isn't a design flaw, we designed it that way!")
This blog post by a member of the IE7 team would confirm that they've at least tried to address this in Vista (but of course that's what you'd expect them to say). It says: "User Interface Privilege Isolation (UIPI) blocks lower-integrity from accessing higher-integrity processes. For example, a lower-integrity process cannot send window messages or hook or attach to higher priority processes This helps protect against "shatter attacks." A shatter attack is when one process tries to elevate privileges by injecting code into another process using windows messages."
Yet another nice legacy "feature" from the single-user-OS days.
The problem with SGI is that they don't really have any compelling products anymore. They have some Linux-based HPC stuff, but I think they've lost the early lead they might have had (as a result of their clustering experience for graphics stuff) in that market to IBM. Then they have some Itanium workstations, which are hideously overpriced, and aside from being Itanium seem to pretty much be a run-of-the-mill workstation in a neat case. (About the only feature they have that you can't get on something from Sun/HP/IBM is a binary compatibility layer for running IRIX applications side-by-side with Linux ones.) And then of course they have some IRIX workstations, for the few people who still have a business reason for staying with IRIX.
... meaning they're not going to be purchasing a lot of new gear.
But most of the people still running IRIX are doing so because they have legacy applications that they need to use, which assumedly already runs on their existing hardware
SGI is rapidly running of of stuff to sell. What they do make looks really neat (gotta love purple), and I'd love to have one under my desk, but it's tough to come up with a business case for the premium it seems like they have to charge in order to stay afloat.
As much as I hate to say it, being someone who's drooled over SGI gear for years, I think they need to exit the hardware business. Or perhaps license the SGI hardware brand out to someone else, to use as their high-end workstation brand. Then pare the company back and concentrate on software for the very high-end visualization markets, and perhaps offer consulting services for people converting from IRIX to Linux.
It seems like they tried to play IRIX for far too long after the writing was on the wall, and the gamble with Itanium didn't help either. Running a single-vendor OS on what's rapidly becoming a single-vendor hardware platform isn't something that many people are going to be interested in.
Just out of curiosity (and since I'm not a Windows user, except for a copy I have installed on a virtual machine to play with), is there any way to avoid getting WGA-ed if you turn on Automatic Updates?
I just turned Auto-Updates off completely, figuring I can just roll the VM back if it gets infected with something, but I'm curious as to whether the user has any control over WGA's installation, or if it just gets slipped in by MS the second you allow automatic installation of updates.
Can you get just the security patches, but refuse to install everything else? Or is WGA considered a "security" patch? (Which would be suitably ironic -- it's 'security' all right, just not for the user.)
If your goal is to create yet still more bloated systems with yet still more arcane data constructs, this is a good start.
... why mess with a good thing?
Well, it's proved to be a pretty good business model so far
I know you're joking (well, maybe), but I often think that the Slashdot crowd fails to appreciate how many people there are in the world -- very smart people, in fact, in many cases -- who are more than willing to take the "dirty" jobs.
Particularly if they're interesting dirty jobs.
The fact that what you're doing can be used to kill people fades away into relative unimportance pretty quickly, if there's a cool technical challenge to be solved, and the salary is right, and the people you get to work with are similarly goal-oriented.
There are a lot of people in the world who spend their days thinking of new and interesting ways to kill others, and I'm willing to bet that most of them probably don't lose sleep at night over it. The human mind has an amazing ability to rationalize -- if not flat-out ignore -- almost anything, and social mores regarding the value of others' lives are no exception.
The quality of AllofMP3.com is a lot better than you can get off of P2P, at least reliably.
There's no fucking around with downloading an album, only to find out that some idiot ripped it at 128kb, which I think sounds worse than a bag full of angry cats. Or you find out the file is fake, or loaded with spyware, or that you have to open a bunch of ports through your firewall in order to get the P2P app to work in the first place, etc.
With AllofMP3, you click on the album, choose your quality level (all the way up to uncompressed 44.1kHz, in some cases) and you get your music. No messing around.
Sounds like a pretty good deal to me.
Apple has always given the impression that they aren't interested in expending a whole lot of effort on DRM, and pretty much do whatever they think the bare minimum that's necessary to pass the studio's "sniff test."
Their attitude seems to be 'release whatever we can squeeze by the studios, and then if something becomes a major problem, we'll change it.' Hence the original versions of iTunes had some neat remote-music-sharing features, but then when they became major sources of piracy and the studios started to complain (assumedly -- I can only imagine the irate phone calls from Sony/Warner/BMG), they got removed.
Obviously as long as Apple has to maintain a relationship with the content monopolies, we probably won't see much in the way of a relaxation of the rules, but it's never seemed like Apple was really the one pushing the restrictions. If they were, their products would look a lot different (more like the early Sony attempts at running a music store).
I'm not being a complete Apple apologist -- they've obviously crippled their products in order to do business with the Sonys of the world, so at the very least they're guilty of some level of collaboration, but if they thought the same way as Sony does on a fundamental level, we'd never have seen the abilities that iTunes has now or had initially.
Slightly OT: does anyone know whether the iPod Video imposes Macrovision on the analog composite video output? I'm guessing that it doesn't, meaning that if you really wanted to un-DRM something that you bought, it would be pretty simple to loop the output of the iPod back into the analog input of a ADC (like an EyeTV or similar) and re-dig the video. Like burning music to CD and back there's an obvious quality loss, which personally I wouldn't find acceptable, but people who happily watch shitty videos produced by somebody in a theater with a camcorder probably wouldn't mind.
I live in a city, which means the post office does not collect outgoing mail, so Netflix is inconvenient
Huh?
What do you mean, it doesn't collect outgoing mail?
I live in a city too, and you can't go two blocks without tripping over a USPS "blue box." Plus, every apartment building that I've ever been in has an outgoing mailbox, right next to the incoming boxes (which are actually superior to the way you do outgoing mail in a rural area -- where you put it in your regular box and put the flag up -- since it can't be stolen).
I'd say that Netflix is much more convenient/practical for people in urban areas than in rural ones, since the delivery turnaround times are usually faster, and in many cases you can send the discs back faster. When I lived in a rural area, I'd stick them in my mailbox and wait for the carrier to pick them up the next morning; now that I live in a city, I put them in the USPS box on the corner, and they go out that afternoon (pickup at 4:30 pm), effectively cutting a day off the mail-in time. When I'm feeling lazy, I just put them in the box on my house and they get picked up the next day.
I can't think of any situation where you can receive mail, but not send it back out. If you use lockable boxes, there should be an outgoing-slot or receptacle nearby. (I think this is required by the DMM.) If you use a box affixed to your house without a flag, then you put your outgoing stuff in it and the carrier will take it out before putting the incoming mail in, and if you have a rural streetside box, then you put it in there and set the flag up.
Any carrier delivering mail will also accept it (assuming it's of "nominal amount" -- you can't hand them a 20 lb package and expect them to carry it around the rest of their route), so if you have mail delivery, you should have a way of sending it back out.
In all seriousness, I know someone who's used themselves as an antenna. It's not particularly hard to do if you have a good transmatch/antenna tuner. That said, I definitely wouldn't recommend doing it. (Not sure what the health effects would be of ultra-QRP down in the HF bands, which is what I think the guy did; only a few hundred mW probably...still, I'm not going to try, thanks.)
When it comes to "making an antenna out of x," where x is virtually any object that's even halfway conductive, someone somewhere has probably tried to push RF through it at some point in the past.
If you're interested in a significantly safer version of the same principle, which doesn't involve licking your finger and touching things which you shouldn't be touching, there is a whole community of people who build salt-water antennas:
http://www.wireservices.com/n9zrt/ila/ila.html
Your attitude is naive.
The GP -- the skydiver -- is paying for the energy he's using when he goes skydiving. He pays for the charter of the plane (probably splitting it with the other people who are going, and also paying for a lot of other stuff, like the pilot, etc.). But he paid for the energy that it's taking to get him up there so he can enjoy his fun floating down.
Likewise, the person driving the Suburban around town to get their groceries is paying for it every time they fill up its tanks at the pump. Maybe you think it's stupid and wasteful, but apparently they disagree -- and they're spending their money on the gas they're burning to prove it.
It's not as if people don't think about the cost of energy -- they do; it's just that their cost/benefit analysis comes out differently than if you did the same thing. The guy going skydiving is saying "it's worth x dollars and y liters of aviation-grade kerosene so I can go parachuting," and the woman with the Suburban is saying "it's worth z dollars and n gallons of gasoline for me to drive around in a car that's bigger than everyone else's."
They're not taking anything from you in doing this -- you could have had the same amount of gas that they did (it's not like it's rationed), if you had wanted to pay for it. When the supply starts to dry up, and the price increases, doubtless people will reconsider whether their gas-intensive recreational activities are worth the cost anymore, or whether their ginormous vehicles are really practical. But for right now, those people are voting in the most important way they can -- with their wallets -- and saying that it is worth it.
Now you could argue that the price of gas is artificially inexpensive, compared to what it should be if all the negative externalities associated with its use were taken into account. I might even agree with you there. (Although I don't think that just increasing taxes on it, whose revenue flows into general funds and is squandered, instead of actually being spent on those externalities, is productive.)
You could also argue, and here I would agree, that the companies and other entities regulating the price of petroleum products today aren't doing a very good job taking into account the future demand for their product. That is to say, they're selling too much of it too quickly right now, in order to reap short-term gains, when instead they could get a lot more for it by extracting it more slowly and selling it at a higher price to those people willing to pay. (Aviation, for instance, is impractical without fossil fuels -- very few other things have the required energy density.) However, this is a wholly separate argument from what people should be able to do with that gas, provided they're buying it at the market rate along with everyone else.
Even when gas is $15 a gallon, there will still be some people who think it's worthwhile to drive an inefficiently large car, or own gas-powered personal watercraft, or go skydiving -- and that's their decision. They have just as much a right to do that with the gas that they buy, as you do, to go wherever you want on your scooter and its tankful, which you bought. As long as both of you are paying the same price for the same product, meaning that you both get to perform the cost/benefit analysis, it's the height of arrogance to pass judgement on others' hobbies.
And when MS falls, who do people turn to?
This is a silly question. The economy detests a vacuum even more than nature does.
To discuss the fall of Microsoft (or more precisely, the Windows desktop) is to say implicitly that something has replaced it.
It would seem to me that one of the strengths of the COTS solutions are that they have fairly slick integrated interfaces for managing access.
If you roll your own, you might well have to set up Samba/CIFS/Netatalk all separately, which could easily become a huge pain. If you want a new share, you'd have to add it manually to all three, and deal with their varying authentication schemes.
I did some Googling around for OSes specifically designed for roll-your-own NAS boxes (which it seems must exist), and came up with some stuff. One of the neatest projects looks like it has died, which is sad: Darma NAS OS. It seemed to be Linux-based and had a Java web-based management GUI, used the usual SMB/NFS/AppleShare, and supported ACLs and some other neat management stuff.
I'm curious what people who've gone the DIY route are using to ease the management hassle that I could easily see a SAN becoming if it's OS is just straight Linux.
I really hate having a proprietary battery cartridge when a few generic rechargeable AAs could have done the job just as well, and let me not pay the hefty premium for the few cents of cheap plastic that they used to bundle them together with. Plus, with standard-size batteries, you have the option of using regular alkalines in a pinch if you really want to -- if you use a proprietary pack and it runs out, you're SOL until it recharges.
The only excuses for using proprietary batteries at all are if the form factor is such that a standard-shaped (AA/LR6 NiMH) won't fit, or the increased energy density of a Li-ion is required.
The best combination is to use standard-sized, replaceable cells and then have an external charging port so that the batteries can be charged without removing them from the device. Unfortunately, few manufacturers of consumer products do this because of the safety features you need to put on the charger in order to keep it from trying to charge the alkalines that people will inevitably put in there, even if you warn them not to.
Open is sometimes painful. But so is life..
No, I think you're just thinking about Goatse.cx.
Hey, if you're going to get served a subpoena, it might as well be in bed.
At least then you don't have to go very far when you feel like just going back to sleep...
Except that this isn't much of a door lock.
This is like somebody going around selling paper-mache deadbolts and telling you about all the horrible things that can happen to your home if you don't buy one. There's an obvious level of dishonesty in selling something and calling it protection (particularly since they go so far as to call it "encryption") when it's fairly trivial to break, and won't protect you against anyone who wants to steal your stuff.
The only thing worse than the criminals themselves are the charlatans who try to foist snake-oil "protection" schemes on unwitting consumers and companies.
I'm going to have to disagree with you there. I know a number of companies that are running IBM z/Series mainframes, in part because they are binary-compatible with programs written for the System/370 (not sure if they're compatible with the S/360, they may be). Heck, IBM designs some of their hardware specifically in order to make it backwards-compatible to systems that there probably aren't any extant examples of, because the software from them still works fine. (EBCDIC page translation hardware, etc.) I doubt they're the only ones.
...") which is horribly obsolete, because removing it would break legacy scripts and applications that people still depend on.
I think you're vastly underappreciating the lifespan of production systems. There is a lot of old green-screen COBOL stuff out there, perhaps not running on the original hardware, but running in various layers of emulation or compatibility modes. Why? Because it still works. Because the fundamental problems that it solves haven't changed that much, and frankly don't change very often.
If there's a lesson programmers should take away from the past 40+ years of commercial software development, it's that software often vastly outlives its original estimated lifespan. (In some cases, maybe even outliving the programmers themselves.) The current post-bubble slowdown in commercial upgrade and adoption cycles, and increased skepticism of IT purchasing, will probably only emphasize this, and anyone starting a project today should plan on a longer lifecycle than they might have anytime before in the past 20 years.
The fact that programs like tar and man have been constantly updated and maintained over the past few decades doesn't really help your case much; you'd do better to look at the syntax of those programs and see how little it's changed in the interim. Tar still has support for syntax ("tar xvf
Building custom, special-purpose software for a 3-to-5-year lifecycle is totally inappropriate, and history has shown that it's generally not the way the world works. If anything, someone coding a custom enterprise ERP system would be better off keeping in mind "how is someone in 30 years, who only knows what we bothered to write down, going to understand what I was thinking when I wrote this?" Because chances are, if you're doing your job right, and the people planning the project were doing their jobs right and found the right 'fundamental problems' to solve, there's no reason why the software itself may not still be in use three decades hence.
I think you're viewing the issue too narrowly.
In any large company, there is a lot of information floating around that you are probably better off not having access to.
While it doesn't make sense to have every secretary and general low-level peon be able to encrypt stuff in such a way that nobody can ever recover them, I would not want to have automatic access to extremely sensitive high-level stuff stored on the executive's systems. Why? Because if somehow it gets leaked, and you have the root password, you have zero plausible deniability. In other words, you become quite easy to scapegoat.
If you work someplace where there isn't any internal backstabbing, and nobody above you would ever consider hanging their poor sysadmin out to dry in order to save their own pillowtalking ass, then great. Let me know where to send my resume.
Generally speaking, while I would want to be sure that I had admin/override rights to all the people below me in a chain of command, I wouldn't want to have those rights to people above me in the chain of command. Not because I'd find the idea of reading my boss' email particularly tempting, but because when something Bad Happens, I want to be able to say with absolute candor, not only didn't I do anything, but I couldn't possibly have done anything.
It's like having the keys to a file cabinet which contains information way above your security clearance level. I wouldn't want to have them, because I don't want to be the guy in the hot seat when somebody way above my pay grade fucks up and decides to find someone expendable to take the blame.
Let the executives have their personal encrypted folders, with a nice big warning sign that says "If you forget your password, NOBODY ELSE WILL BE ABLE TO ACCESS THIS." If they forget their passwords, then it's their problem, or if they maliciously encrypt things as they're tendering their resignation, then it's Legal's problem. The last thing I'd want to do is make it my problem.
It's way worse when "the porn" is pictures of other people that you took when they were sleeping.
google will be able to scan your bedroom and tell you if your enviornment will cause you cancer or not :P
And the answer will always be "Yes."
I was surprised and pleased to see Andy Ihnatko on there. I guess I'd missed him for a few years -- ever since he stopped doing the second-to-last-page columns for MacWorld (and before that, if memory serves, MacUser), I'd been wondering whatever happened to him. There was a considerable period during what I call the "dark ages" of the Mac when the only reason I kept up my subscription was for his column.
After all, props are still in order if only for being the inventor of "Web That Smut," possibly the only good thing to ever happen as the result of the Communications Decency Act. (The original column is here, archived via the Wayback Machine, but I'm not sure if Slashdot is going to mangle the link.)
And of course there's also the millenial version, Web That DeCSS!
That's a great anecdote, and I don't think that you can hit that point hard enough.
If somebody came to you and said "hey, I've got this great new way to build a bridge! Instead of making up plans, we'll just start building it! We'll build it out of popsicle sticks first, and then we'll go in and add some steel beams, and toss some pavement on top of that," you'd say they were insane. Nobody does stuff like that in the real world -- yet that's exactly what a lot of poorly-managed 'agile' software projects are doing. They're getting short-term prototyping gains but at the cost of maintainability and probably stability as well.
Rather than figuring anything out ahead of time -- actually answering the hard questions like "what do we want this software to do and how do we want to do it?" they just start making something. It's like just giving some steelworkers a pile of rebar on either side of the river and telling them to build towards the center and figure the details out later.
I think one of the biggest problems in software development, and it's really endemic, is an underappreciation of the pre-development work: requirements analysis, specification development, even simple stuff like the clear division of job roles and responsibilities. If you get that stuff done, the actual coding ought to be an academic exercise, not a seat-of-the-pants experiment.
Part of the problem lies with managers who don't understand software, and just take any opportunity to compress schedules and make themselves look better, and another problem is with "programmer culture," where people think the ideal way to solve a complicated problem is just to put a half-dozen developers in a room for a weekend with a few gallons of Mountain Dew, an Amex card, and the number of the nearest Domino's Pizza. (Although to be fair, this attitude seems to be less common among developers who have SOs/families, or are used to 40-hour workweeks.)
While concentrating on "getting it out the door" may solve the problem in the short run, it's almost certainly not going to give you neat, easily-maintainable, well-documented code. And when you're looking at the long-term maintainance costs, it sometimes can be better to not have anything at all, than to have a lot of spaghetti code that somebody is just going to have to rewrite down the road, when they can't figure it all out.