Slim Devices' Squeezebox2 is very, very good. It's about the size of a VHS tape, has a truly beautiful, professional-grade display, and talks to a central server. It outputs both digital and analog, either passing data via coax and optical, or using the high-quality onboard DACs.
On my fairly forgiving (rather warm/laid back) main speaker system, I wasn't able to hear any difference at all when switching back and forth between the DACs on the Onkyo 901 and the SB2. I don't have golden ears or anything, but they're reasonably good, and digital and analog mode sounded identical to me. The 901 retailed at $1500 (though you could buy them at around $950), so the SB2 matching that means it's doing a pretty good job. If you happen to have gear that's better than mine, and you think you can hear a difference.... well, that's what the coax and optical outs are for.
The unit also has a headphone jack, which sounds good. It does not, however, seem to have a huge amount of onboard power, so you'd probably want a separate headphone amp for high-impedance cans like the Sennheiser HD580s or 600s. (They still sound good without one, but have much more authority with more power driving them.)
The higher-end models come with built-in 802.11g wireless, which is more than fast enough to support several streams (ie, several players), though if you got seriously into the networked music thing, with lots of stations, you'd probably want to do it with wires. The wireless model will also bridge to Ethernet via the single RJ45 jack. If you add a hub, you can bridge a whole stack of stuff to your WiFi.
You can control the boxes from either the included remote, using a very easy interface, or via web browser. If you have several SB2s, you can coordinate them all to play at the same time, so that you have synced music in several rooms or the whole house. (I believe it will do subgroups as well, but I have only the one and can't test that.) I'm not sure if units will sync from the remote or only from the web interface. I'm fairly sure you have to CREATE the sync via web browser, but I suspect it will probably just work from then on. I believe you'd hit play on any unit in a group, and they would all start playing.
Of course, if that DOESN'T work, you can add the feature yourself. The server software is Perl and very open-source. I believe the boxes themselves run Linux and can be hacked on, but honestly, the software is just so good that I can't really imagine wanting to. Maybe if I had a second one... that display really is neat, and it'd be fun to play with it for other stuff. I'd just hate to break my only one.
The box natively speaks MP3, FLAC, and WAV. The server software can translate from many other music formats, and will sync with iTunes if you have that. (I don't think it can play Apple's DRM, so you'd have to crack that first.) It understands CUE/BIN images, which is GREAT, because that's how I have all my music archived. It actually supports CUE/FLAC too, so I compressed all my music to save some space. I have verified that I get bit-perfect output... playing a DTS-encoded WAV file through the SB2 (at full volume, of course) gives me music on a DTS-enabled receiver, not just noise. If the bitstream is damaged in any way, DTS doesn't work. It just comes out as a hiss. So a DTS file is a great test of bit-perfect transfer... if you hear music, you're delivering a truly lossless stream.
If you archive your CDs losslessly, then you'll probably get better results from this unit than you'd get from most 'real' CD players. You can't scratch a CUE file, or get it dusty. I have no way to test it, but I'd guess that eliminating the vagaries of the optical pickup would probably diminish jitter a great deal. I've never learned how to hear digital clock jitter myself, but some people are very focused on the issue. I don't know if it REALLY matters, but if it does, my guess is that the SB2 should do a better job than most real CD transports would.
I have been in the workforce for more than twenty years. The great majority of jobs I've had have been cubicle based, from insurance to several technology companies to bioscience. There's a pretty darn good solution to the noise problem. It's called 'being quiet'. As long as the walls are reasonably high (I've seen extremely short cubicles, which don't work well), and your coworkers are polite, it's a great way to get a lot of work done.
Offices are expensive. If you're THAT bothered by distractions, you can buy huge jars of very good foam earplugs for like $8 at your local drugstore. You don't need to hear everything going on around you. You don't need to see it either. Wear earplugs for a few weeks. Realize how little you're missing by not paying attention to everything around you. Soon, you'll likely develop virtual earplugs that will serve you just as well, and cost nothing.
Demanding that your employer provide the workforce with offices is saying "I require that you quadruple your rent to suit me." It is very, very unlikely that you are that much better than everyone else, nearly all of whom work just fine in cubes.
Your complaints about poor management, though, are spot-on. That is the telltale of a bad company. If you realize that the management is dumb, get the hell out.
As always in an Ask Slashdot, there's not enough info in your post to make any clear recommendations. Your specs are pie-in-the-sky wild.. there's really very little to work with here. But I'll try to give you some pointers.
I'm assuming you want two Windows 98 PCs to provide streaming audio to some arbitrary number of clients. Sending one stream isn't that hard... as others have said, that would be about 1.5megabits per stream. However, in ordinary TCP, you have to send a unique stream per client... even though it's the exact same data going to all clients. This adds up *fast*. So the number of clients you want to serve at any given time is the determining factor for how hard the problem is.
To give you an idea of the number ranges you're talking about, your network fabric is one potential bottleneck. Even on a 100Mb switch, you'll have a hard time exceeding about 60 connections. If you're willing to settle for MP3-compressed files (and LAME sounds REALLY good), you can cut your bandwidth needs to no more than 320k per client with almost no sound loss. 160k LAME still sounds very nice, and would probably let you support around 600 clients on a 100Mbit connection.
However, I doubt that Win98, even on a powerful machine, could stream that much data without croaking, particularly with the 600-connection scenario. It has trouble with multiple filesharing connections, a core function of the OS... running a heavy-duty server application on 98 is likely to be pretty troublesome.
What you really WANT is to be able to send the stream just once, and have all your clients tap into the stream and play the music. Multicast will do this... it is a one-to-many protocol. But your server, network infrastructure, and clients have to support it.
So what clients and server software do you use? I have no idea. I'd suggest starting with a search for 'multicast' on Freshmeat and going from there.
Overall, this is a hard problem. It's absolutely solvable, but it will take both expertise and money... the more of the former you have on tap, the less of the latter you'll need.
Even with the needed expertise, I don't think you can do this on the cheap. You're very, very likely to have to spend money. If they're talking about using HUBS, you're not even on the same page... this project, if it's meant as more than a toy for five people at a time, will most likely require a fairly expensive backbone.
Your campus IT department probably has both the expertise and the network backbone already in place, so your first stop should be them.
(I'm being interrupted, so I can't edit this as well as I'd like... hopefully any mistakes won't be too awful.)
It's worth pointing out that a US citizen of 1905 would, with some training, be perfectly comfortable in 2005. We're still doing the same things, and we're organized in basically the same way. A lot of things are a lot easier, but they're not fundamentally different. We have a bunch of magic toys, like electric refrigeration, air conditioning, ubiquitous automobiles, and the Internet, but we're doing fundamentally the same things with them that we were in 1905. The amount of future shock would be far, far lower than in the timeframes you mention.
The single biggest change is probably the Internet, but I tend to think that, at least so far, its impact is a bit overstated. Yes, we all have access to tons of information very easily that we didn't have before, but that also means we have access to bad information much more easily, too. With the physical costs of paper publication, there was a gatekeeper effect that improved knowledge quality. If you go to a library, the chances of anything you read being true are far higher than doing the same research on the Net. I'm sure that there are far more profound shifts that will occur because of the Net, but I don't think they've really happened yet.
Until we figure out a new energy source that is an order of magnitude better than what we have now, it strikes me that things won't improve that much more. In fact, in many areas, they stand a very high chance of regression.
Thank you for the correction. Normally, before I posted something like that, I'd test it to be sure it was right... but I didn't have access to a Linux machine and couldn't. That's why I included the 'untested!' warning. I don't normally use the -n command because I very rarely have situations where it would matter. I do use the --replace command with xargs all the time. That was the real reason I replied... the GGP poster thought that xargs wouldn't do the command substitution, which it will.
One problem with using find to execute the program directly is that you have to run the find. xargs will work with any input, so you can output find to a text file, and then run xargs repeatedly on that without having to re-run the search. On most modern systems, finds run subsequent to the original will execute very, very quickly, and thus the extra overhead won't really matter, but A) not all filesystems are fast, and B) perhaps the underlying filesystem will have changed, and you need to run your later xargs on the exact same set of files, even after weeks or months have elapsed. So it strikes me that making sure people know xargs exists, even if it's not the ideal way to accomplish this specific task, may be more beneficial than teaching the EXACT right way to do it.
Best of both worlds would probably be this thread, where both methods are demonstrated.... one incorrectly, sadly. Sorry about that.
Xargs has the --replace option, which allows you to embed the argument somewhere in the middle, much like your 'find' example above. I haven't tested this (I'm not near a Unix machine right now), but from memory, this should do the same thing as your last command:
The --replace option tells it to substitute the arguments for {}. If you use the --replace=foo syntax, then the word 'foo' will be replaced instead. {} is the default.
As other threads have pointed out, the -n argument lets you do fewer process spawns. If there are 100 files in a directory, it's no big deal, but if there are 100,000, then the 50x fork reduction could really matter.
The biggest reason to remove dust is because it insulates heat. Chips are designed around the idea of operating exposed to air. Most chips generate some heat, and if they're in a thick blanket of dust, they'll run hotter than they otherwise would. The more recent the equipment, the more pronounced the effect, because newer stuff runs much hotter than older-generation equipment. Heat eventually causes failures.
That 486-33 in the corner, in other words, might continue to work fine for 20 years in three feet of dust. It generates so little heat to begin with that insulating it isn't that big a deal. That machine you're talking about that's eight years old probably isn't a lot faster than that.
But if you bought a brand new Athlon 64 4800+ and put it into the same environment, it could potentially die within months.... particularly if the motherboard is passively cooled. The CPU itself might be fine (the spinning fan prevents the worst of the dust from building up), but the hot Northbridge could easily overheat.
At one job, a few years ago, I installed a small, simple SAP program, SAPRouter. It was basically a program that would route net connections over a modem into a foreign network. I don't remember the details very well, because it has been six or seven years, but some of the stuff I definitely do recall. My memory of cursing, intensely, for DAYS is clear and bright. SAPRouter was among the stupidest pieces of software I've ever been forced to work with.
It was just bizarre. Out in left field.... way, way out. They implemented an entire routing protocol, kind of like IP, but very poorly. It was completely unrelated to any other form of routing I've seen.
From what I remember, you had to install the router software on a PC that had a modem. That was going to do the call out. (VPN wasn't common at the time, you had to use a modem for a network backdoor.) But then you had to configure the client to talk to that PC over the network... and you also, if I remember correctly, had to tell it about every hop it had to take in the foreign system.
In other words, it would be like having to manually configure your PC with every hop between you and Slashdot before you could read web pages. And if one of the hops changed, well, too bad. No Web for you.
There was more, too, lots more, but I have lost the details. All I remember is that it was problem after problem after problem for DAYS. And this is relatively simple software.
The documentation was horrible too. It made no sense at all. (which shouldn't be that surprising, really, since the program made no sense either.) SAP was kind of bleeding edge in one regard, and provided fairly complete Web documentation. Sadly, instant access helped clarity not a whit. I ended up taking three or four days and making repeated calls to SAP to get the stupid thing working. It felt like I was trying to push my head through a cheese grater. I'm not an idiot... I was learning IP routing at the time, and I can assure you, it was _trivial_ in comparison.
In some ways(the bad ones), SAPRouter reminded me of learning Netware for the first time. Netware was full of weirdnesses that didn't make sense at first. But after you'd been working with a given feature for awhile, nearly always there was an 'aha!' Netware had a payoff for the struggle... you'd finally see why they had modeled a given problem the way they had, and it was inevitably elegant, powerful, and aesthetic all at once. It was hard to figure out their context, but once you did, their solutions made beautiful sense. They thought out problems incredibly thoroughly, and solved them completely.
SAPRouter wasn't like that. It felt like, well... like a bureaucracy that's very sure of its own brilliance. They reimplemented, badly, what IP was already doing. It was grossly inferior, complex when it didn't need to be. Once I understood their context, and why they solved the problem how they did, my conclusion was that they were idiots. It felt like something designed by people who had *no idea* what routing is or how it should work.
To be fair, it was nicely stable once it was up. I didn't have to fool with it anymore after it was (finally) running.
Basically.... don't be so serenely certain these admins are idiots. The reason you're good at figuring this stuff out is because smarter people than you (or me) took the time to make it (relatively) easy. They chose good models and clean implementations, so the programs are fairly easy to configure and use. You being good at building solutions from open source stuff is partially your brainpower, but the lion's share of the credit goes to the original designers. You had an easy time of it because, for the most part, the software is fairly easy. It could have been far, far worse.
If you're sensitive to screen refresh rates, then the DLP sets are a nightmare. Just walking past them in the store is enough to drive me nuts... they flicker like crazy, especially in your peripheral vision.
That is so frustrating... I've been using PC Power and Cooling supplies for years. I have always liked them a lot, and I've always wondered how they'd rate compared with other "good" supplies. But these sites NEVER rate them. I wonder why?
Optimally, we would remove the reader temporarily from his reality and time. We would collect the flow of images, sounds, feelings, and events that passed into Saddam's mind and project them as with a Zeiss Planetarium projection instrument. The reader would see the Universe from Saddam's point in space. Events would flow by the reader as they flowed by Saddam.
Oh please. That's not research. I don't know what that is, but it's pretty out there.
Yes, we found one artillery shell with mustard gas in it. One shell. It was shown to have been manufactured in the 1980s. (when we knew they did indeed have some chemical weapons.) It was in with other artillery shells, and had probably been misplaced. One shell is not a WMD, by the way. Even a whole lot of mustard gas, while very unpleasant, isn't really that much more effective than conventional weapons. Calling mustard gas a WMD is stretching the definition to the breaking point... it is a chemical weapon, but it's only really useful for attacking armies and area interdiction. Because it requires so much of the chemical to do anything, and kills so few people exposed, it's not at all suitable for terrorism.
80 tons of the stuff was no threat to the US. A MILLION tons of the stuff would have been no threat. And while it has a pretty good lifespan in cold climates, I very much doubt that any gas manufactured in the 1980s would still be useful after twenty years in the desert. This round was useless, and it's extremely likely that everything else manufactured in the same timeframe is useless too.
In other words, even if Saddam DIDN'T destroy them, it doesn't matter because A) mustard gas isn't much more dangerous than conventional weapons, and B) it wouldn't be any good anymore anyway.
Your claims of sarin are completely uncorroborated, to my knowledge. If your source for that is the Zeiss Planetarium, well, I think I'll wait for more evidence.
If you'd like a GOOD article about the lies we were told, read this.
You're spouting misinformation. Rush Limbaugh is not a news source. They WERE NOT trying to build nukes. That is absolutely, unequivocally, a LIE. They had been trying in the 1980s... you're citing evidence from back then as evidence of them being a current threat. The yellowcake thing, by the way, was shown to be a forgery.. completely untrue.
Read this article for a very long and detailed analysis of some of the lies told to the American public. They were deliberate and knowing in doing so. This article mostly deals with the claims of nuclear weapons, but where there's smoke, there's fire. If they were willing to just blatantly make shit up (which is EXACTLY what they did about the nukes), then why should their claims of chem/bioweapons be trusted?
Read that article. Read every word. And then think about it. Maybe, just maybe, the fact that you're being fed a line of shit by Hannity, Limbaugh, and the administration might penetrate.
BTW, most chemical weapons only last a few years, particularly in the desert, so large stockpiles of them would indeed disappear. Even if Saddam HAD hidden them, they'd be entirely useless after twenty years. Chemical weapons require constant remanufacturing... a whole chemical industry behind them. They're not something you just make and have forever.
Mustard gas can last quite some time, but it's not suited for use as a terrorist weapon. It requires really large amounts of the stuff to do much. It's more of an area interdiction thing, and a method to wound enemy soldiers and slow down enemy armies. Terrorists want stuff like sarin or VX. Even if Saddam had had a million tons of mustard gas, it would have been no significant threat to the US.
As far your question about proof... you do realize how ridiculous it is, right? I hereby demand that you prove that there are no little green men on the Moon. If you can't disprove it, then they must exist.
WMDs in Iraq were pretty much exactly that: little green men.
We had complete, unfettered access to Iraq way before we invaded. Hans Blix kept saying, (approximately) "We don't see anything here, we need you to be clearer about the intelligence you're trumpeting. We see nothing here on the ground" And, of course, we couldn't be any more clear, because the little intelligence we DID have was deliberately misinterpreted and used as an excuse to whip the country into a war frenzy. The White House KNEW this. They were claiming that Iraq was trying to build nuclear weapons when that was clearly and demonstrably false, well before we invaded.
In other words, they knowingly and purposely lied to get us to go to war. The reason we didn't find any WMDs is because they were never there. UN Inspectors had full access to anything they wanted, without delay.
If you use Acrobat Reader, the UI freeze on loading a PDF in a new tab is a well-known bug. I'm not sure if there will ever be a resolution... the last time I read about it, there seemed to be lots more finger-pointing than fixing.
That's not entirely true. I have looked and looked for the quote, and haven't found it, but Linus once said something like, "Hardware is inherently reliable. There's no reason why the software running on it shouldn't be." This was a long time ago, probably sometime around '96, and it seems to have disappeared.... both literally and figuratively.
It was never about 'perfect' software, but it WAS about software that didn't EVER break. That was the biggest reason I started using Linux. It was something I could really trust. (of course, at the time, Windows 95 was the best Microsoft could do, which was a toy in comparison.)
From my perspective, it used to be "Here's software you can really trust. It's hard to get working, and doesn't do as much as you're used to, but it won't ever fall over."
Nowadays, it seems to be more "Here's software that does a lot of really cool stuff, but doesn't always work. We don't care very much about that part."
In some ways, from my perspective, Microsoft and Linux have switched places. If I had used those two sentences ten years ago, the second would absolutely have been aimed at the beast in Redmond. Now.... well, I certainly wouldn't care to argue that Linux is a more stable desktop than XP. More secure, absolutely. But more stable, barring a virus or somesuch? That's not an argument I'd want to make.
To be fair, several times that they've said that, things have indeed gotten a lot better. 98->NT->2000 were all pretty substantial improvements. 2000->XP, well... not so great.
XP has its warts and we all love to bash Microsoft, but being fair... if people aren't actively attacking/exploiting it, it's extremely solid. The security sucks, but the stability of the OS itself is really very, very good.
We're mad at them now for all the spyware/exploits, but we used to be mad at them because the OS didn't work. It fell over on its own, no outside assistance required. It's enormously better than it was ten years ago.
So at least some of the time when they say that, they're right. The problem is that the finish line keeps moving.
Well, I'm hopeful they can nail things down and get them stable, but their focus doesn't seem to be on quality first. I think it was Rik van Riel who said that it was perfectly okay for only 1 stable release in 3 to actually be stable. I kid you not. I'd link it for you, as it's in my old comments. Unfortunately, I can't get to my old submissions, as I don't pay Slashdot anymore. So you'll have to find the quote yourself. lwn.net definitely has it somewhere in their archives.
It's worth pointing out that the whole move of Linux into the server market was accidental. It was always being written as a desktop Unix. It just happened to be so amazingly robust that it made a dynamite server, and took over a good chunk of the internet. That'd be a good book title, "The Accidental Server". Unfortunately, the development model never changed to match the actual use of the system.
The reason I started using Linux to begin with was because it didn't ever break... it didn't have as many features as Windows, but it just never, ever, EVER fell over. The 2.2 kernel was probably the most bulletproof piece of software I've ever run on a PC. 2.4 never got to the sheer solidity of 2.2... on good hardware it's quite robust, but I saw a number of machines where stressing it would lock it up after a few days. (from the kernel messages, it looked like it might be bugs in the (different) network drivers.) 2.6, relatively speaking, has just been a disaster. They won't leave it alone long enough to let it stabilize... they insist on jamming new code into every release, and dropping old releases very quickly. (the new 2.6.X setup.) So I can't get my bugfixes without new features if I want to use a vanilla kernel.
People, of course, instantly bash me and say 'you're stupid, you should be using a distribution kernel'. I'm doing that now, even though I liked rolling my own, but I shouldn't have to. The dev team's attitude seems to be 'ship it and let the distros debug it'... which, as far as I'm concerned, is waving one's hand in the air, hoping that someone else will fix it. Linus' kernel should be rock-solid. It's the center around which the Linux universe turns. Their new attitude means that both Mandrake and Red Hat will have to spend time fixing the same problems, possibly in incompatible ways. And it means that programs may run on Red Hat, but not on Mandrake or vanilla Linux, or some other variation on that. There needs to be a gold standard, a One True Linux. We don't have that anymore, and I think the inevitable result will be to balkanize the community. Without that central kernel, switching from one distro to another, particularly with commercial software like Oracle, becomes much chancier. You'll end up with vendor lock-in... Oracle will run only on Red Hat's kernel, so you're stuck with Red Hat's distro. That's not supposed to happen with Open Source, but it looks nearly inevitable if we can't get a stable kernel at the center.
Your entire comment appears to consist of "you're stupid. Microsoft maintains backward compatibility because of money. Linux maintains backward compatibility through 'standard engineering practices'[whatever the hell those are], and because everything in Linux is ancient. You're dumb, you're stupid, you haven't been using computers very long, go away."
What with all the insults, you're awfully light on actual content in your reply. Ignoring those, I don't even see a clear argument. What, exactly, are you asserting? I think I see 'everything in Linux is old', but that's just so ludicrous that I'll assume I'm misunderstanding. You may want to elaborate a bit.
By the way, I'm not likely to be an astroturfer. I expect you can probably figure out why.
I realize that base Unix is very old. However, it's very old and very, very simple in terms of the POSIX APIs. Now, I'm a sysadmin, rather than a programmer, but it has always been my understanding that POSIX was a very limited subset of the Unix libraries; if you wrote to that subset, you were guaranteed portability. From what I remember, the last time I looked (years and years ago), there just isn't a whole lot there. It's a solid set of base functions, but it's quite primitive. There's nothing like, say, DCOM, or DirectX or DirectSound. It's a solid base, but as a guess, (and I invite correction from more knowledgeable people), it covers maybe 10% of the API ground handled by more modern environments. The QT/KDE and GNOME APIs are not very old. And the Linux-specific extensions to the POSIX standard can't be older than about 12 years.
So yes, there's an ancient standard at the base, but most modern code is going to be hitting libraries that are quite young, relatively speaking.
All the complexity in KDE and GNOME has many of the same benefits that Windows does, like easy integration of web browsers into other applications. I wonder, though, if they're not getting themselves into the same pickle that Microsoft has. When everything is integrated and interdependent, one tiny code change can blow up an awful lot of other stuff.
Mind you, I LIKE these desktops, and I appreciate the features very much. But the programmers of old, at the dawn of the Unix era, were some of the most phenomenally intelligent people ever. Most software work today isn't being done by the same kind of luminary. I'm fundamentally trying to make the observations that A) Microsoft has a lot of smart people too, and blew it, and B) the smart people in the open source world may be making the same mistakes, by inventing desktop systems with APIs to do everything from balancing your checkbook to flossing your teeth.
Now, it'll be EASIER to support them in open source, because it's much easier to modify programs to match API changes. That alone will probably make a significant difference. But it doesn't change the fact that APIs don't easily go away, and lugging them around gets expensive, even in open source. (Binary compatibility is far worse.)
I talked about Linux in that sense because I'm irritated with it, and because I was thinking about their great efforts toward binary compability in userspace. That's a great feature, and I appreciate it, but I wonder how much it costs, relatively speaking. I was reaching a bit, trying to be somewhat charitable about the reasons behind the poor state of the 2.6 kernel.
If, as you appear to say, everything in Linux is ancient, and "standard engineering practices" will somehow magically make everything run correctly, then don't you think your comments are particularly damning of its code quality?
Way back when, people were flipping out about the 65000 bugs in Windows 2000. I kept saying, "No, you don't understand... this means they can COUNT the bugs now. They have a process that's good enough to detect those bugs, so they'll be able to fix them.' Being able to claim with some precision that you have 65000 bugs is a huge, huge step forward from not knowing how many you have at all. And, as it turns out, Windows 2000 was possibly the best OS Microsoft ever shipped. This was not coincidence.
I'm much more hopeful that Vista will be a real product after reading this article. It sounded like fluff/vaporware, but now it's starting to sound like it may have actual benefits for real people. (I likely still won't use it, because of the DRM/Palladium evilness inside, and I'll suggest to other people that they not do so either. But it may actually offer some real technical benefits along with the evil.)
I doubt it will ever be secure. As Microsoft has spent billions demonstrating, you cannot retrofit security.
The open source people might be able to learn from this process change at Microsoft. The 2.6 kernel has been very, very low quality, at least compared to earlier Linux releases. Even I myself have seen at least one of the problems.... bugs in the kernel directly cost me a couple hundred dollars, because I replaced a hard drive when it had nothing wrong with it at all. I was bitten by ACPI bugs, which mysteriously caused hard drive failures. I figured out the problem after the new drive started failing too, but I was about $200 poorer for it. As far as I remember, I haven't replaced non-broken hardware due to OS bugs since Win95... not exactly the best example to follow.
I also worry about the desktop environments... they're getting so large and complex, they're starting to look like Windows. Tons of features with lots of interdependencies. I'm sure the code is a lot better than a lot of the stuff in Windows, but clean, tight code will protect against only so much bloat and overcomplex design.
I'm starting to think that part of the reason the open source code was so very much better than Windows' was because it was a fresh start, with no backward compatibility to worry about.
I wonder if, once the kernel, KDE, and GNOME guys have to lug around twenty years' worth of backward compatibility, they'll be exactly like Windows... bloated, buggy, and insecure. The last couple of years haven't looked too promising in that regard.
Um, we have spent three hundred billion dollars to make more extremists. Invading Iraq and linking that to the so-called "War on Terror" was an outright lie. No WMDs. No link to Al Qaeda.
Invading Iraq because of 9/11 was precisely equivalent to invading Mexico for Pearl Harbor.
It's worth pointing out that there were no terrorists in Iraq before we invaded. Days when there are only two or three car bombs are now good days there.
When you look at the Bush team's absolutely inept handling of the Katrina disaster, four years after 9/11 and his campaigns consisting largely of "If you vote for that Kerry guy, you'll die".... after all his rhetoric about Protecting the Homeland... what on earth gives you any confidence that these guys can find their asses with two hands? Why on earth do you think that the Iraq occupation is being run competently? Or that we should even be there in the first place?
Those damn liberals, always criticising. Expecting actual results and stuff. Unpatriotic. Oughta just shoot 'em.
Doesn't Mercury have sufficient gravity for an atmosphere? Just because it's been boiled away by the Sun doesn't mean it couldn't potentially have one, if it were in Earth's orbit. And Pluto has gravity enough to hold an atmosphere, obviously, since it has one to freeze out in the deep dark. If you'll notice, that's exactly why I said 'has sufficient gravity to hold an atmosphere in Earth's orbit'. I didn't say 'has atmosphere', I said 'could potentially hold one in the correct orbit'.
Slashdot Mirror
I saw one comment from a sound engineer somewhere..... "Creative is telling you that, given a pile of hamburger, they can make a cow."
Slim Devices' Squeezebox2 is very, very good. It's about the size of a VHS tape, has a truly beautiful, professional-grade display, and talks to a central server. It outputs both digital and analog, either passing data via coax and optical, or using the high-quality onboard DACs.
On my fairly forgiving (rather warm/laid back) main speaker system, I wasn't able to hear any difference at all when switching back and forth between the DACs on the Onkyo 901 and the SB2. I don't have golden ears or anything, but they're reasonably good, and digital and analog mode sounded identical to me. The 901 retailed at $1500 (though you could buy them at around $950), so the SB2 matching that means it's doing a pretty good job. If you happen to have gear that's better than mine, and you think you can hear a difference.... well, that's what the coax and optical outs are for.
The unit also has a headphone jack, which sounds good. It does not, however, seem to have a huge amount of onboard power, so you'd probably want a separate headphone amp for high-impedance cans like the Sennheiser HD580s or 600s. (They still sound good without one, but have much more authority with more power driving them.)
The higher-end models come with built-in 802.11g wireless, which is more than fast enough to support several streams (ie, several players), though if you got seriously into the networked music thing, with lots of stations, you'd probably want to do it with wires. The wireless model will also bridge to Ethernet via the single RJ45 jack. If you add a hub, you can bridge a whole stack of stuff to your WiFi.
You can control the boxes from either the included remote, using a very easy interface, or via web browser. If you have several SB2s, you can coordinate them all to play at the same time, so that you have synced music in several rooms or the whole house. (I believe it will do subgroups as well, but I have only the one and can't test that.) I'm not sure if units will sync from the remote or only from the web interface. I'm fairly sure you have to CREATE the sync via web browser, but I suspect it will probably just work from then on. I believe you'd hit play on any unit in a group, and they would all start playing.
Of course, if that DOESN'T work, you can add the feature yourself. The server software is Perl and very open-source. I believe the boxes themselves run Linux and can be hacked on, but honestly, the software is just so good that I can't really imagine wanting to. Maybe if I had a second one... that display really is neat, and it'd be fun to play with it for other stuff. I'd just hate to break my only one.
The box natively speaks MP3, FLAC, and WAV. The server software can translate from many other music formats, and will sync with iTunes if you have that. (I don't think it can play Apple's DRM, so you'd have to crack that first.) It understands CUE/BIN images, which is GREAT, because that's how I have all my music archived. It actually supports CUE/FLAC too, so I compressed all my music to save some space. I have verified that I get bit-perfect output... playing a DTS-encoded WAV file through the SB2 (at full volume, of course) gives me music on a DTS-enabled receiver, not just noise. If the bitstream is damaged in any way, DTS doesn't work. It just comes out as a hiss. So a DTS file is a great test of bit-perfect transfer... if you hear music, you're delivering a truly lossless stream.
If you archive your CDs losslessly, then you'll probably get better results from this unit than you'd get from most 'real' CD players. You can't scratch a CUE file, or get it dusty. I have no way to test it, but I'd guess that eliminating the vagaries of the optical pickup would probably diminish jitter a great deal. I've never learned how to hear digital clock jitter myself, but some people are very focused on the issue. I don't know if it REALLY matters, but if it does, my guess is that the SB2 should do a better job than most real CD transports would.
Overall, it has mo
I have been in the workforce for more than twenty years. The great majority of jobs I've had have been cubicle based, from insurance to several technology companies to bioscience. There's a pretty darn good solution to the noise problem. It's called 'being quiet'. As long as the walls are reasonably high (I've seen extremely short cubicles, which don't work well), and your coworkers are polite, it's a great way to get a lot of work done.
Offices are expensive. If you're THAT bothered by distractions, you can buy huge jars of very good foam earplugs for like $8 at your local drugstore. You don't need to hear everything going on around you. You don't need to see it either. Wear earplugs for a few weeks. Realize how little you're missing by not paying attention to everything around you. Soon, you'll likely develop virtual earplugs that will serve you just as well, and cost nothing.
Demanding that your employer provide the workforce with offices is saying "I require that you quadruple your rent to suit me." It is very, very unlikely that you are that much better than everyone else, nearly all of whom work just fine in cubes.
Your complaints about poor management, though, are spot-on. That is the telltale of a bad company. If you realize that the management is dumb, get the hell out.
THAT'S your sign, not cubicles.
As always in an Ask Slashdot, there's not enough info in your post to make any clear recommendations. Your specs are pie-in-the-sky wild.. there's really very little to work with here. But I'll try to give you some pointers.
I'm assuming you want two Windows 98 PCs to provide streaming audio to some arbitrary number of clients. Sending one stream isn't that hard... as others have said, that would be about 1.5megabits per stream. However, in ordinary TCP, you have to send a unique stream per client... even though it's the exact same data going to all clients. This adds up *fast*. So the number of clients you want to serve at any given time is the determining factor for how hard the problem is.
To give you an idea of the number ranges you're talking about, your network fabric is one potential bottleneck. Even on a 100Mb switch, you'll have a hard time exceeding about 60 connections. If you're willing to settle for MP3-compressed files (and LAME sounds REALLY good), you can cut your bandwidth needs to no more than 320k per client with almost no sound loss. 160k LAME still sounds very nice, and would probably let you support around 600 clients on a 100Mbit connection.
However, I doubt that Win98, even on a powerful machine, could stream that much data without croaking, particularly with the 600-connection scenario. It has trouble with multiple filesharing connections, a core function of the OS... running a heavy-duty server application on 98 is likely to be pretty troublesome.
What you really WANT is to be able to send the stream just once, and have all your clients tap into the stream and play the music. Multicast will do this... it is a one-to-many protocol. But your server, network infrastructure, and clients have to support it.
So what clients and server software do you use? I have no idea. I'd suggest starting with a search for 'multicast' on Freshmeat and going from there.
Overall, this is a hard problem. It's absolutely solvable, but it will take both expertise and money... the more of the former you have on tap, the less of the latter you'll need.
Even with the needed expertise, I don't think you can do this on the cheap. You're very, very likely to have to spend money. If they're talking about using HUBS, you're not even on the same page... this project, if it's meant as more than a toy for five people at a time, will most likely require a fairly expensive backbone.
Your campus IT department probably has both the expertise and the network backbone already in place, so your first stop should be them.
(I'm being interrupted, so I can't edit this as well as I'd like... hopefully any mistakes won't be too awful.)
It's worth pointing out that a US citizen of 1905 would, with some training, be perfectly comfortable in 2005. We're still doing the same things, and we're organized in basically the same way. A lot of things are a lot easier, but they're not fundamentally different. We have a bunch of magic toys, like electric refrigeration, air conditioning, ubiquitous automobiles, and the Internet, but we're doing fundamentally the same things with them that we were in 1905. The amount of future shock would be far, far lower than in the timeframes you mention.
The single biggest change is probably the Internet, but I tend to think that, at least so far, its impact is a bit overstated. Yes, we all have access to tons of information very easily that we didn't have before, but that also means we have access to bad information much more easily, too. With the physical costs of paper publication, there was a gatekeeper effect that improved knowledge quality. If you go to a library, the chances of anything you read being true are far higher than doing the same research on the Net. I'm sure that there are far more profound shifts that will occur because of the Net, but I don't think they've really happened yet.
Until we figure out a new energy source that is an order of magnitude better than what we have now, it strikes me that things won't improve that much more. In fact, in many areas, they stand a very high chance of regression.
Thank you for the correction. Normally, before I posted something like that, I'd test it to be sure it was right... but I didn't have access to a Linux machine and couldn't. That's why I included the 'untested!' warning. I don't normally use the -n command because I very rarely have situations where it would matter. I do use the --replace command with xargs all the time. That was the real reason I replied... the GGP poster thought that xargs wouldn't do the command substitution, which it will.
One problem with using find to execute the program directly is that you have to run the find. xargs will work with any input, so you can output find to a text file, and then run xargs repeatedly on that without having to re-run the search. On most modern systems, finds run subsequent to the original will execute very, very quickly, and thus the extra overhead won't really matter, but A) not all filesystems are fast, and B) perhaps the underlying filesystem will have changed, and you need to run your later xargs on the exact same set of files, even after weeks or months have elapsed. So it strikes me that making sure people know xargs exists, even if it's not the ideal way to accomplish this specific task, may be more beneficial than teaching the EXACT right way to do it.
Best of both worlds would probably be this thread, where both methods are demonstrated.... one incorrectly, sadly. Sorry about that.
As other threads have pointed out, the -n argument lets you do fewer process spawns. If there are 100 files in a directory, it's no big deal, but if there are 100,000, then the 50x fork reduction could really matter.
That stopped being true when the government started ignoring the parts of the Constitution it found inconvenient.
The biggest reason to remove dust is because it insulates heat. Chips are designed around the idea of operating exposed to air. Most chips generate some heat, and if they're in a thick blanket of dust, they'll run hotter than they otherwise would. The more recent the equipment, the more pronounced the effect, because newer stuff runs much hotter than older-generation equipment. Heat eventually causes failures.
That 486-33 in the corner, in other words, might continue to work fine for 20 years in three feet of dust. It generates so little heat to begin with that insulating it isn't that big a deal. That machine you're talking about that's eight years old probably isn't a lot faster than that.
But if you bought a brand new Athlon 64 4800+ and put it into the same environment, it could potentially die within months.... particularly if the motherboard is passively cooled. The CPU itself might be fine (the spinning fan prevents the worst of the dust from building up), but the hot Northbridge could easily overheat.
At one job, a few years ago, I installed a small, simple SAP program, SAPRouter. It was basically a program that would route net connections over a modem into a foreign network. I don't remember the details very well, because it has been six or seven years, but some of the stuff I definitely do recall. My memory of cursing, intensely, for DAYS is clear and bright. SAPRouter was among the stupidest pieces of software I've ever been forced to work with.
It was just bizarre. Out in left field.... way, way out. They implemented an entire routing protocol, kind of like IP, but very poorly. It was completely unrelated to any other form of routing I've seen.
From what I remember, you had to install the router software on a PC that had a modem. That was going to do the call out. (VPN wasn't common at the time, you had to use a modem for a network backdoor.) But then you had to configure the client to talk to that PC over the network... and you also, if I remember correctly, had to tell it about every hop it had to take in the foreign system.
In other words, it would be like having to manually configure your PC with every hop between you and Slashdot before you could read web pages. And if one of the hops changed, well, too bad. No Web for you.
There was more, too, lots more, but I have lost the details. All I remember is that it was problem after problem after problem for DAYS. And this is relatively simple software.
The documentation was horrible too. It made no sense at all. (which shouldn't be that surprising, really, since the program made no sense either.) SAP was kind of bleeding edge in one regard, and provided fairly complete Web documentation. Sadly, instant access helped clarity not a whit. I ended up taking three or four days and making repeated calls to SAP to get the stupid thing working. It felt like I was trying to push my head through a cheese grater. I'm not an idiot... I was learning IP routing at the time, and I can assure you, it was _trivial_ in comparison.
In some ways(the bad ones), SAPRouter reminded me of learning Netware for the first time. Netware was full of weirdnesses that didn't make sense at first. But after you'd been working with a given feature for awhile, nearly always there was an 'aha!' Netware had a payoff for the struggle... you'd finally see why they had modeled a given problem the way they had, and it was inevitably elegant, powerful, and aesthetic all at once. It was hard to figure out their context, but once you did, their solutions made beautiful sense. They thought out problems incredibly thoroughly, and solved them completely.
SAPRouter wasn't like that. It felt like, well... like a bureaucracy that's very sure of its own brilliance. They reimplemented, badly, what IP was already doing. It was grossly inferior, complex when it didn't need to be. Once I understood their context, and why they solved the problem how they did, my conclusion was that they were idiots. It felt like something designed by people who had *no idea* what routing is or how it should work.
To be fair, it was nicely stable once it was up. I didn't have to fool with it anymore after it was (finally) running.
Basically.... don't be so serenely certain these admins are idiots. The reason you're good at figuring this stuff out is because smarter people than you (or me) took the time to make it (relatively) easy. They chose good models and clean implementations, so the programs are fairly easy to configure and use. You being good at building solutions from open source stuff is partially your brainpower, but the lion's share of the credit goes to the original designers. You had an easy time of it because, for the most part, the software is fairly easy. It could have been far, far worse.
It could have been SAP.
If you're sensitive to screen refresh rates, then the DLP sets are a nightmare. Just walking past them in the store is enough to drive me nuts... they flicker like crazy, especially in your peripheral vision.
That is so frustrating... I've been using PC Power and Cooling supplies for years. I have always liked them a lot, and I've always wondered how they'd rate compared with other "good" supplies. But these sites NEVER rate them. I wonder why?
It's like bar codes on your forehead, without the pesky tattoo.
This is the ultimate surveillance tool. It trumps all other forms of ID.
Read the New York Times article. It is extremely clear, interesting, and makes solid assertions that are well-researched and thought out.
Bashing it as 'liberal' is just a way of conveniently ignoring truths you don't like.
Read the article and then talk about specifics. They did their homework. Will you do yours?
Oh please. That's not research. I don't know what that is, but it's pretty out there.
Yes, we found one artillery shell with mustard gas in it. One shell. It was shown to have been manufactured in the 1980s. (when we knew they did indeed have some chemical weapons.) It was in with other artillery shells, and had probably been misplaced. One shell is not a WMD, by the way. Even a whole lot of mustard gas, while very unpleasant, isn't really that much more effective than conventional weapons. Calling mustard gas a WMD is stretching the definition to the breaking point... it is a chemical weapon, but it's only really useful for attacking armies and area interdiction. Because it requires so much of the chemical to do anything, and kills so few people exposed, it's not at all suitable for terrorism.
80 tons of the stuff was no threat to the US. A MILLION tons of the stuff would have been no threat. And while it has a pretty good lifespan in cold climates, I very much doubt that any gas manufactured in the 1980s would still be useful after twenty years in the desert. This round was useless, and it's extremely likely that everything else manufactured in the same timeframe is useless too.
In other words, even if Saddam DIDN'T destroy them, it doesn't matter because A) mustard gas isn't much more dangerous than conventional weapons, and B) it wouldn't be any good anymore anyway.
Your claims of sarin are completely uncorroborated, to my knowledge. If your source for that is the Zeiss Planetarium, well, I think I'll wait for more evidence.
If you'd like a GOOD article about the lies we were told, read this.
You're spouting misinformation. Rush Limbaugh is not a news source. They WERE NOT trying to build nukes. That is absolutely, unequivocally, a LIE. They had been trying in the 1980s... you're citing evidence from back then as evidence of them being a current threat. The yellowcake thing, by the way, was shown to be a forgery.. completely untrue.
Read this article for a very long and detailed analysis of some of the lies told to the American public. They were deliberate and knowing in doing so. This article mostly deals with the claims of nuclear weapons, but where there's smoke, there's fire. If they were willing to just blatantly make shit up (which is EXACTLY what they did about the nukes), then why should their claims of chem/bioweapons be trusted?
Read that article. Read every word. And then think about it. Maybe, just maybe, the fact that you're being fed a line of shit by Hannity, Limbaugh, and the administration might penetrate.
BTW, most chemical weapons only last a few years, particularly in the desert, so large stockpiles of them would indeed disappear. Even if Saddam HAD hidden them, they'd be entirely useless after twenty years. Chemical weapons require constant remanufacturing... a whole chemical industry behind them. They're not something you just make and have forever.
Mustard gas can last quite some time, but it's not suited for use as a terrorist weapon. It requires really large amounts of the stuff to do much. It's more of an area interdiction thing, and a method to wound enemy soldiers and slow down enemy armies. Terrorists want stuff like sarin or VX. Even if Saddam had had a million tons of mustard gas, it would have been no significant threat to the US.
As far your question about proof... you do realize how ridiculous it is, right? I hereby demand that you prove that there are no little green men on the Moon. If you can't disprove it, then they must exist.
WMDs in Iraq were pretty much exactly that: little green men.
We had complete, unfettered access to Iraq way before we invaded. Hans Blix kept saying, (approximately) "We don't see anything here, we need you to be clearer about the intelligence you're trumpeting. We see nothing here on the ground" And, of course, we couldn't be any more clear, because the little intelligence we DID have was deliberately misinterpreted and used as an excuse to whip the country into a war frenzy. The White House KNEW this. They were claiming that Iraq was trying to build nuclear weapons when that was clearly and demonstrably false, well before we invaded.
In other words, they knowingly and purposely lied to get us to go to war. The reason we didn't find any WMDs is because they were never there. UN Inspectors had full access to anything they wanted, without delay.
If you use Acrobat Reader, the UI freeze on loading a PDF in a new tab is a well-known bug. I'm not sure if there will ever be a resolution... the last time I read about it, there seemed to be lots more finger-pointing than fixing.
That's not entirely true. I have looked and looked for the quote, and haven't found it, but Linus once said something like, "Hardware is inherently reliable. There's no reason why the software running on it shouldn't be." This was a long time ago, probably sometime around '96, and it seems to have disappeared.... both literally and figuratively.
It was never about 'perfect' software, but it WAS about software that didn't EVER break. That was the biggest reason I started using Linux. It was something I could really trust. (of course, at the time, Windows 95 was the best Microsoft could do, which was a toy in comparison.)
From my perspective, it used to be "Here's software you can really trust. It's hard to get working, and doesn't do as much as you're used to, but it won't ever fall over."
Nowadays, it seems to be more "Here's software that does a lot of really cool stuff, but doesn't always work. We don't care very much about that part."
In some ways, from my perspective, Microsoft and Linux have switched places. If I had used those two sentences ten years ago, the second would absolutely have been aimed at the beast in Redmond. Now.... well, I certainly wouldn't care to argue that Linux is a more stable desktop than XP. More secure, absolutely. But more stable, barring a virus or somesuch? That's not an argument I'd want to make.
I think XP might win, in a virus-free world.
To be fair, several times that they've said that, things have indeed gotten a lot better. 98->NT->2000 were all pretty substantial improvements. 2000->XP, well... not so great.
XP has its warts and we all love to bash Microsoft, but being fair... if people aren't actively attacking/exploiting it, it's extremely solid. The security sucks, but the stability of the OS itself is really very, very good.
We're mad at them now for all the spyware/exploits, but we used to be mad at them because the OS didn't work. It fell over on its own, no outside assistance required. It's enormously better than it was ten years ago.
So at least some of the time when they say that, they're right. The problem is that the finish line keeps moving.
Well, I'm hopeful they can nail things down and get them stable, but their focus doesn't seem to be on quality first. I think it was Rik van Riel who said that it was perfectly okay for only 1 stable release in 3 to actually be stable. I kid you not. I'd link it for you, as it's in my old comments. Unfortunately, I can't get to my old submissions, as I don't pay Slashdot anymore. So you'll have to find the quote yourself. lwn.net definitely has it somewhere in their archives.
:)
It's worth pointing out that the whole move of Linux into the server market was accidental. It was always being written as a desktop Unix. It just happened to be so amazingly robust that it made a dynamite server, and took over a good chunk of the internet. That'd be a good book title, "The Accidental Server". Unfortunately, the development model never changed to match the actual use of the system.
The reason I started using Linux to begin with was because it didn't ever break... it didn't have as many features as Windows, but it just never, ever, EVER fell over. The 2.2 kernel was probably the most bulletproof piece of software I've ever run on a PC. 2.4 never got to the sheer solidity of 2.2... on good hardware it's quite robust, but I saw a number of machines where stressing it would lock it up after a few days. (from the kernel messages, it looked like it might be bugs in the (different) network drivers.) 2.6, relatively speaking, has just been a disaster. They won't leave it alone long enough to let it stabilize... they insist on jamming new code into every release, and dropping old releases very quickly. (the new 2.6.X setup.) So I can't get my bugfixes without new features if I want to use a vanilla kernel.
People, of course, instantly bash me and say 'you're stupid, you should be using a distribution kernel'. I'm doing that now, even though I liked rolling my own, but I shouldn't have to. The dev team's attitude seems to be 'ship it and let the distros debug it'... which, as far as I'm concerned, is waving one's hand in the air, hoping that someone else will fix it. Linus' kernel should be rock-solid. It's the center around which the Linux universe turns. Their new attitude means that both Mandrake and Red Hat will have to spend time fixing the same problems, possibly in incompatible ways. And it means that programs may run on Red Hat, but not on Mandrake or vanilla Linux, or some other variation on that. There needs to be a gold standard, a One True Linux. We don't have that anymore, and I think the inevitable result will be to balkanize the community. Without that central kernel, switching from one distro to another, particularly with commercial software like Oracle, becomes much chancier. You'll end up with vendor lock-in... Oracle will run only on Red Hat's kernel, so you're stuck with Red Hat's distro. That's not supposed to happen with Open Source, but it looks nearly inevitable if we can't get a stable kernel at the center.
Wow, that was quite a segue. Sorry about that.
Your entire comment appears to consist of "you're stupid. Microsoft maintains backward compatibility because of money. Linux maintains backward compatibility through 'standard engineering practices'[whatever the hell those are], and because everything in Linux is ancient. You're dumb, you're stupid, you haven't been using computers very long, go away."
What with all the insults, you're awfully light on actual content in your reply. Ignoring those, I don't even see a clear argument. What, exactly, are you asserting? I think I see 'everything in Linux is old', but that's just so ludicrous that I'll assume I'm misunderstanding. You may want to elaborate a bit.
By the way, I'm not likely to be an astroturfer. I expect you can probably figure out why.
I realize that base Unix is very old. However, it's very old and very, very simple in terms of the POSIX APIs. Now, I'm a sysadmin, rather than a programmer, but it has always been my understanding that POSIX was a very limited subset of the Unix libraries; if you wrote to that subset, you were guaranteed portability. From what I remember, the last time I looked (years and years ago), there just isn't a whole lot there. It's a solid set of base functions, but it's quite primitive. There's nothing like, say, DCOM, or DirectX or DirectSound. It's a solid base, but as a guess, (and I invite correction from more knowledgeable people), it covers maybe 10% of the API ground handled by more modern environments. The QT/KDE and GNOME APIs are not very old. And the Linux-specific extensions to the POSIX standard can't be older than about 12 years.
So yes, there's an ancient standard at the base, but most modern code is going to be hitting libraries that are quite young, relatively speaking.
All the complexity in KDE and GNOME has many of the same benefits that Windows does, like easy integration of web browsers into other applications. I wonder, though, if they're not getting themselves into the same pickle that Microsoft has. When everything is integrated and interdependent, one tiny code change can blow up an awful lot of other stuff.
Mind you, I LIKE these desktops, and I appreciate the features very much. But the programmers of old, at the dawn of the Unix era, were some of the most phenomenally intelligent people ever. Most software work today isn't being done by the same kind of luminary. I'm fundamentally trying to make the observations that A) Microsoft has a lot of smart people too, and blew it, and B) the smart people in the open source world may be making the same mistakes, by inventing desktop systems with APIs to do everything from balancing your checkbook to flossing your teeth.
Now, it'll be EASIER to support them in open source, because it's much easier to modify programs to match API changes. That alone will probably make a significant difference. But it doesn't change the fact that APIs don't easily go away, and lugging them around gets expensive, even in open source. (Binary compatibility is far worse.)
I talked about Linux in that sense because I'm irritated with it, and because I was thinking about their great efforts toward binary compability in userspace. That's a great feature, and I appreciate it, but I wonder how much it costs, relatively speaking. I was reaching a bit, trying to be somewhat charitable about the reasons behind the poor state of the 2.6 kernel.
If, as you appear to say, everything in Linux is ancient, and "standard engineering practices" will somehow magically make everything run correctly, then don't you think your comments are particularly damning of its code quality?
Way back when, people were flipping out about the 65000 bugs in Windows 2000. I kept saying, "No, you don't understand... this means they can COUNT the bugs now. They have a process that's good enough to detect those bugs, so they'll be able to fix them.' Being able to claim with some precision that you have 65000 bugs is a huge, huge step forward from not knowing how many you have at all. And, as it turns out, Windows 2000 was possibly the best OS Microsoft ever shipped. This was not coincidence.
I'm much more hopeful that Vista will be a real product after reading this article. It sounded like fluff/vaporware, but now it's starting to sound like it may have actual benefits for real people. (I likely still won't use it, because of the DRM/Palladium evilness inside, and I'll suggest to other people that they not do so either. But it may actually offer some real technical benefits along with the evil.)
I doubt it will ever be secure. As Microsoft has spent billions demonstrating, you cannot retrofit security.
The open source people might be able to learn from this process change at Microsoft. The 2.6 kernel has been very, very low quality, at least compared to earlier Linux releases. Even I myself have seen at least one of the problems.... bugs in the kernel directly cost me a couple hundred dollars, because I replaced a hard drive when it had nothing wrong with it at all. I was bitten by ACPI bugs, which mysteriously caused hard drive failures. I figured out the problem after the new drive started failing too, but I was about $200 poorer for it. As far as I remember, I haven't replaced non-broken hardware due to OS bugs since Win95... not exactly the best example to follow.
I also worry about the desktop environments... they're getting so large and complex, they're starting to look like Windows. Tons of features with lots of interdependencies. I'm sure the code is a lot better than a lot of the stuff in Windows, but clean, tight code will protect against only so much bloat and overcomplex design.
I'm starting to think that part of the reason the open source code was so very much better than Windows' was because it was a fresh start, with no backward compatibility to worry about.
I wonder if, once the kernel, KDE, and GNOME guys have to lug around twenty years' worth of backward compatibility, they'll be exactly like Windows... bloated, buggy, and insecure. The last couple of years haven't looked too promising in that regard.
Um, we have spent three hundred billion dollars to make more extremists. Invading Iraq and linking that to the so-called "War on Terror" was an outright lie. No WMDs. No link to Al Qaeda.
... what on earth gives you any confidence that these guys can find their asses with two hands? Why on earth do you think that the Iraq occupation is being run competently? Or that we should even be there in the first place?
Invading Iraq because of 9/11 was precisely equivalent to invading Mexico for Pearl Harbor.
It's worth pointing out that there were no terrorists in Iraq before we invaded. Days when there are only two or three car bombs are now good days there.
When you look at the Bush team's absolutely inept handling of the Katrina disaster, four years after 9/11 and his campaigns consisting largely of "If you vote for that Kerry guy, you'll die".... after all his rhetoric about Protecting the Homeland
Those damn liberals, always criticising. Expecting actual results and stuff. Unpatriotic. Oughta just shoot 'em.
Doesn't Mercury have sufficient gravity for an atmosphere? Just because it's been boiled away by the Sun doesn't mean it couldn't potentially have one, if it were in Earth's orbit. And Pluto has gravity enough to hold an atmosphere, obviously, since it has one to freeze out in the deep dark. If you'll notice, that's exactly why I said 'has sufficient gravity to hold an atmosphere in Earth's orbit'. I didn't say 'has atmosphere', I said 'could potentially hold one in the correct orbit'.
And Titan doesn't orbit the Sun.