Re:So much easier to knock down than to build up
on
Top 10 Apple Flops
·
· Score: 1
I would very strongly suggest that you not state things as graven-in-stone fact when you aren't 100% sure that they are actually factual.
The Apple//e and//c spelled it that way, with two slashes. As far as I can tell, the Apple 2 series never used Roman numerals. The Apple 3 may have.
In real life, of course, 2, II,//, ][... were all perfectly acceptable. Everyone knew what you were talking about, and I don't think anyone cared which version you used.
Re:So much easier to knock down than to build up
on
Top 10 Apple Flops
·
· Score: 1
Both the physical case and the ROM in the machine said Apple ][. Not 2, not II, but ][.
One thing that people don't often mention is that, while the lag was getting pretty terrible, the game was still mostly playable. It might take several minutes(!) for an Auction House query to return, or for an auction to be created, or for your email to show up, but the transactions DID eventually happen.
Instead of just blowing up completely, by and large, WOW fails fairly gracefully. The engineering in that is non-trivial. I don't think people realize just how good that code is. Getting a system that stays reasonably stable under completely untested loads is really, really hard. I am VERY impressed with the quality of their design and code work.
And, yes, some data did get lost... the servers did eventually seize up and crash completely, and often there'd be some data lost. But, at least in my case, it was never much more than a skill point or two, or a few hundred experience.... twenty minutes of lost playtime. I'm sure some people had a worse experience than I did, that's the nature of random data loss, but I wasn't badly affected.
When you consider the sheer scale of what they're doing.... they had TWO HUNDRED THOUDAND PEOPLE AT ONCE playing their game not long ago. The scale of that just boggles the imagination. If you assume 32kbits/second down, and 2kbits up (probably a bit skinny, but I'll try to err against Blizzard here), that's an aggregate total of 10,880,000,000 bits per second. Roughly 10 gigabits, or total saturation of an OC-192. Just the FIREWALLING on that kind of traffic is a HUGE project! Admittedly, they've broken that up into 3 or 4 datacenters, but doing firewalling and connection tracking on a mere 2.5gigabits is still pretty daunting. And that is completely ignoring the application servers, the load balancing, the inter-server communication, the databases..... just 1% of this project is a HUGE BIG DEAL.
The fact that we were able to pile in there at that kind of speed and the game didn't seize up and die completely is a resounding, amazing success. I'm sure the Blizzard guys aren't feeling too great about how things went by now, but.... guys, you kicked ASS. You did somethiung that has never been done before, a level of complexity nobody else has ever reached, got loaded down with about four times as much traffic as you were expecting.... and STILL mostly succeeded.
I have every faith that you'll work out the remaining kinks and bottlenecks.
By the way, the last couple days, on Uther, have been quite good... I think I got one disconnect in two days, and there really hasn't been any lag. They may nearly have the problems fixed. I haven't been thinking about bugs, just about slaughtering beasties.:-)
Wow, a front page article on Slashdot that amounts to, "gee, how do I build a server?" Spiffed up a bit with trendy, techie-sounding words, but cripes. This is FP news-worthy?
That said... if all you're doing is file serving, a tiny machine by modern standards is fine. 64 megs of ram in a P3/400 would make a very solid home server. If you want to use software RAID, though, it's a good idea to go faster... you'd want at least 1ghz for that, maybe 2, depending on how much traffic you were sending to the box and how patient/impatient you are.
Since it's going in your basement and you have no worries about size or noise levels, get a big whompin' case with lots of 5.25" slots. Cremax makes some nice enclosures that will let you put 5 3.5" drives into 3 5.25" bays, with good fans for cooling. They have multiple variants. I'm using the SCSI flavor, but you can get them in SATA too (and IDE, I think, but I'm less sure about that.)
I have an older 3ware 8500 RAID card, and it's dismally slow at RAID 5, even though it's supposedly 'optimized' for it. I don't know if the newer SATA versions are better, but while they are well-supported in Linux, and, being hardware RAID, are a total no-brainer from an admin perspective, my generation of cards was horribly, horribly slow. I get at least four times the performance using Software RAID on an Athlon 1900+.
This is how my network server looks:
Big case; 400W PC Power and Cooling power supply; ASUS A7V333 motherboard; Athlon 1900+, I think just 266mhz FSB (not sure); 1 gig of RAM (nice for caching, not at all necessary to have this much); Ancient video card, Matrox Milllenium 2, I think; 3com 3c509 network card; ICP Vortex 32-bit RAID controller, bought used. The first one I got was dead... had to replace it. I got it pretty cheap, intending it for another project that fell through, and so I ended up using it at home instead. I think it was about $100, but I'm not sure now. These boards KICK ASS. Great linux support, VERY fast. Awesome hardware. 6 18-gig 10KRPM SCSI drives; machine boots from this array, and Debian is installed here; 2 Cremax 5-in-3 SCSI enclosures; 1 3ware 8500+, in JBOD mode (software RAID is WAY faster); 4 80 gig IDE drives (small, but I set this part of the system up a long time ago)
The SCSI array is damn fast, an excellent spot for interactive, disk-intensive things like IMAP or big compiles, while the slower IDE array is ideal for filesharing.
You should be able to set up a similar system for, oh, $1500? And keep in mind... this is HUGE overkill for a home network, it would be a solid backbone for a company up to about 50 people... though it might need more drive space, and I'd probably want redundant power supplies in a really central machine. You could run mail, internal DNS, DHCP, a squid proxy, internal webserver, and Samba for that many people without it even working that hard.
File sharing is fundamentally a tremendously simple thing, and it just hardly takes anything at all to do a perfectly fine job. Once upon a time this was akin to rocket science, but at this point, even a garbage $200 PC from Walmart would probably be an okay fileserver.
Again: the specs on the machine above are wild overkill... swatting a fly with a sledgehammer. But if you want to spend that much money, or you have most of the parts laying around the house anyway, it'll do a damn good job.
You just don't get what this MEANS. You're parroting what the kernel devs are saying, without truly thinking about it. They apparently aren't really thinking about it either.
Point 1: What they are saying with this model is that they want to do all the fun stuff, not the bug fixing...sort of waving their hands in the air and expecting that other people will make their broken software suck less. This is an enormous change, and it benefits NOBODY but them. Ultimately, it doesn't even benefit them, because eventually it's going to slow or even stop Linux adoption.
Point 2: If Linus' "stable" tree isn't guaranteed to be as stable as he can possibly make it, then we're going to end up with DOZENS of different 'stable' kernels, all of which are slightly different. We already have that problem, but this is going to make it much worse. All the different distros are going to be solving the same problems, but many of them are going to come up with DIFFERENT SOLUTIONS. And, being human, many of these guys will believe that THEIR way is the best, and that the solutions the OTHER companies came up with are inferior.
So as a Serious, High-End Program Vendor, like Oracle, who is comitted to supporting Linux, I'm now forced to ask, "Which Linux? Red Hat? Suse? Novell? Debian?" They alreayd have to do this to some degree, but now they get a whole extra level of complexity... do we support 2.6.7 only? Do we certify multiple kernels? If we choose more than a couple of kernels across maybe two distros, our test load will become unmanageable.
Point 3: There IS NO MORE ONE TRUE LINUX. Always before, there has been a core, stable kernel, at which you could point a finger and say with authority, "THIS IS LINUX", and be right. If you write something that works with the One True Linux, and then it doesn't work with Mandrake or Red Hat or what have you, then you have a very clear and obvious point of approach to get it fixed. And they can't waffle... if it works with One True Linux and not with their product, then they are at fault. That simple.
Instead, what we're ending up with here is finger-pointing... it works on Red Hat, but not on vanilla Linux, and it kind of works on Mandrake but acts funny on Tuesday, and it erases Debian systems completely. Who's to blame here? WHO KNOWS?! There's no One True Linux to test agaist. The kernel devs will point at the distributions to make broken things work... the distributions will point at the kernel devs, and end users are going to start pointing to Windows and the BSDs.
If I were a serious developer, I'd look at that operating system model and run in terror. Oracle must be kicking themselves bigtime for such a huge commmitment to a platform that is suddenly disintegrating underneath them.
Without a rock-stable center, there IS NO LINUX, it's just a bunch of semi-compatible custom forks. It's UNIX all over again!
This is an absolute disaster on every front but one.. the kernel developers get to have more fun and spend less of that icky bugfixing time. Yay. Go team.
I am seriously looking at that. I thought about adding it into the original post, but the inevitable reaction would be 'don't let the door hit you in the ass on the way out'. I have a lot of inertia with regard to Linux, as I'm very used to it and have been for ten years, but if the development process doesn't go back to the old model (or something like it) soon, my annoyance is likely to exceed my inertia.
Linux, at the moment, OWNS the words "secure and "reliable" in the marketplace. Once it loses that reputation, it will probably never again own them. Every day that the development process continues in the present mode, Linux's credibility is damaged. Once it goes past a certain point, the damage will be unrecoverable, even if the software returns to its original quality. The world thinks that if something is free it must suck. The present development model will confirm that belief... and once people realize that their suspicions were correct all along, they'll NEVER AGAIN change their minds.
Developers: the other operating systems are NOT STANDING STILL. Microsoft gets better every day. FreeBSD has enough features to be a useful desktop, and makes an excellent server. Linux has huge momentum, but if you don't stop this developer-focused insanity, they are going to make you irrelevant.
The real world wants things that WORK, not feature-laden piles of crap that don't run right.
I can't find the exact quote in a quick google search, but as I recall, one of Linus' main reasons to write Linux was because hardware is very reliable... and there's no reason software shouldn't be just as good.
Have we forgotten so quickly? Is it really about features now, and not rock-solid stability?
As far as I can see, the testing on Linux is "write a bunch of code and toss it out where the suck, er, end users can test it." Back when this was all in the development code, it was okay. Putting out the current piles of smoking garbage in the "stable" tree, on the other hand, is not.
And the ONLY REASON they got stable was because features stopped being added. (2.4 was terrible in that regard, horribly broken until, what, 2.11? 2.12?). It stabilized after...gee...they stopped adding new code!
Your example PROVES the point. Go to 2.7 and play in your sandbox. Do all the free work you like in the development branch. That process has worked for 10 years.
This new model, on the other hand, benefits almost nobody.
From a security perspective, the current Linux development model is a nightmare. Introducing new features into the 'stable' codeline is not how to reduce bugs and problems.
If I'm running 2.6.8, and a new bug comes out, I'm forced to either A) upgrade to the most recent 'stable' kernel, introducing new features about which I know nothing, and which themselves may be security problems, or B) can hope that someone will backport the security fixes to the kernel version I'm running. I don't know enough about kernel development to patch it myself, but I can no longer just drop in the most recent stable kernel and expect it to work unchanged.
A sysadmin's most precious commodities are time and attention. With this new development model, suddenly I am forced to either pay a great deal of attention (and a great deal of time) to each and every version of the Linux kernel, or I need to pay a vendor to do it for me.
The kernel developers are, in my opinion, shirking their single most fundamental duty... to ship a stable, secure product. Suddenly, because it's easier for them, they have abrogated the fundamental contract, that they will write great software. (buggy, insecure software is not great, no matter how many features it has.) They just wave their hands vaguely in the air and say tha the distributions will take care of those problems.
Guys, it's not gonna happen. The way you get stable software is by not adding features. In your case, by branching off to 2.7, and letting us beat the unchanging (except for bugfixes) 2.6 tree to death. If you keep adding features, you keep adding bugs. That's how it works.
You had this NAILED for years and years... there is a huge community that has built up around the fundamental social contract that even numbered kernels are as stable and secure as you know how to make them, and the odd-numbered branches are the home for new code and new features. Changing that contract simply becuase it makes your lives mildly easier is a hugely destructive idea. You may save yourselves a bit of work, but you create an enormous amount of it for everyone else.
Ted T'So said:
Not all 2.6.x kernels will be good; but if we do releases every 1 or 2 weeks, some of them *will* be good. The problem with the -rc releases is that we try to predict in advance which releases in advance will be stable, and we don't seem to be able to do a good job of that. If we do a release every week, my guess is that at least 1 in 3 releases will turn out to be stable enough for most purposes. But we won't know until after 2 or 3 days which releases will be the good ones.
In other words, he thinks it's perfectly fine if only 1 out of 3 'stable' kernels are actually stable.
This is not acceptable.
You can bet that Bill has a big grin on his face about this one. If I want new features with my security fixes, I might as well choose Microsoft and their service packs.
You, sir, are out of your mind. Some people are stupid, therefore all complexity is to be removed. You make vague generalities about how some people somewhere (no actual proof, mind you) blew it on ACLs, so ACLs are bad. Argument by assertion is not proof.
A good ACL system is more powerful, more flexible, and conceptually one heck of a lot easier than the very primitive Unix permissions. The Byzantine workarounds required to implement a truly complex permissions setup in Unix make it far, FAR easier to make mistakes.
If we grant your assertion that people are stupid, then a very precise permissions system is much to be desired, since there is far more of a chance to make a bad mistake mapping a knotty permissions problem onto the simplistic Unix design.
Like it or not, some people NEED complex permissions sets. Unix wasn't designed the way it was designed 'to be secure', Unix was designed the way it was because that's ALL THEY THOUGHT THEY NEEDED THIRTY YEARS AGO.
There's a REASON groups like the NSA are pushing the complex permission structures like SELinux... it's because what we have now is grossly inadequate. Just as the Unixy OSes don't have the language to describe precisely enough what sorts of permissions programs should have, the Unixy filesystems (mostly) don't have permissions structures that easily cover real-world scenarios.
ACLs have that power, and just because some people use them badly is no reason to dismiss them. In the real world, they WORK BETTER.
A well-designed ACL system is leaps and bounds better than Unix permissions. The problem is mostly that people implement ACLS very, very poorly, scattering permissions all over the filesystem where they are hard to find.
Microsoft has been doing this right for a long time, and they were pushing the AGLP standard in the NT 4.0 days (the last Windows I truly administered in a very complex environment.) AGLP means:
A)ccounts go in G)lobal groups; (the ones on your domain controller) Global groups go in L)ocal groups; (the ones sitting on your fileservers) Local groups get P)ermissions. (the actual filesystems)
How this translated for me was this:
Global groups, ones on the domain controller, specify GROUPS OF PEOPLE; Local groups, ones on physical servers, describe SETS OF PERMISSIONS (at least) three groups are made for each share on a server: Share RO, Share RW, Share Admin. Additional Local groups might be needed if you had weird permissions requirements, but I never did. Permissions are assigned ONCE EVER to the filesystem, children inheriting from their parents.
So, when you're building a server, you decide what shares you want. You create 3 groups for each share, and assign the correct rights to each group on each share. You then load Domain groups into your local groups. If I'm building a machine for Accounting, I might put the "Accounting Staff" domain group in the "Accounting Share RW" local group. I'd probably put the Domain group of "Accounting Managers" (even if there was only one manager, I'd still name it plural and put him in it) into "Accounting Share Admin" group. And I might put the "Upper Management" domain group in the RO group.
You just always, always stick with this standard. If you need a specific person to have specific access to a specific share, you *create a special domain group for them*. If you can't think of anything better, perhaps "People with RO Access to Accounting Share". You then put that group in the server's local group. From then on, if you need to give that specific permission to others, you just stick them in that special Domain group. Note that it's better to have Global groups be more functional descriptions rather than permissions descriptions, but no model handles 100% of all possible permissions weirdness perfectly.
By creating sensible groups at the Domain level, and putting individual accounts in the proper Domain groups, you remove all need to EVER change permission on files. You don't ever, ever have to touch a filesystem again to change permissions, assuming you were sufficiently granular with your Local groups and filesystem permissions to begin with. You can manage literally MILLIONS OF FILES with just a few clicks in User Manager. What used to take hours (reassigning permissions on a zillion files) now takes only seconds... just swapping people into and out of groups. (or, perhaps, swapping Global groups in and out of Local groups.)
NT's ACL system, in other words, can let you abstract your information policy, even make it somewhat visual, so that at each level you're only dealing one thing. You can make vast, sweeping security policy changes with just a few clicks and WITHOUT BUGS.
(Note: there are some additions to this model that are necessitated by how Active Directory works, so don't take this as literal gospel. It's still a good model, but it needs some adjustment to work properly with AD. I'm not familiar enough with the specifics to tell you, but I know 2K has added a couple more group types, so it may require another level of abstraction.)
I haven't seen ANYTHING in Unix that will let me both have that kind of granularity and sweeping power.
Unix permissions, in other words, SUCK ROCKS. They're HORRIBLE. ACLS are both far more elegant and far more powerful.
I have a Koolance case, the PC-602 I think. It was one of the first they shipped, and I bought it for its silence, and MAN was I disappointed. It did a good job of cooling, but it was very loud.
Recently, I upgraded to an Athlon 64, and this time around I bought a Koolance Exos... I bought it with thirty feet of external tubing, figuring I'd put the cooler in the closet or in the next room -- behind a closed door. But for whatever reason, the Exos AL is a LOT quieter than the visually identical 602. It's so quiet, in fact, that I have never bothered moving the cooler into the closet... it sits on my desktop, and I can barely hear it. The G4 is much, much louder.
I'm cooling three hard drives, two WD Raptor 36gs and a WD 250 something or other, (the kind with extra cache, JB?), the motherboard chipset, an Athlon Mobile 3200+, and a GeForce 6800GT. I'm very pleased with how cool the hard drives run in particular... they put out a lot of heat, and the waterblocks + thermal goop do an extremely good job. They run just *slightly* warmer than room temperature.
I haven't tried overclocking... I figure I'll do that later instead of upgrading, when the machine starts to feel too slow. I suspect I've got a TON of headroom... even with all that stuff I'm cooling, I never get much above 37C. I suspect I'll be able to increase heat output quite a bit and stay comfortably cool. I actually bought it to be quiet, but it's nice to know that I can make it go fast too.
Upshot: the older cases WERE obnoxiously loud. The current Exos AL is VERY quiet. I assume any case you'd buy from them now would be similar.
Note that to use a hard drive cooling block on more than one hard drive, you need either the special Koolance cases or some way to drill custom holes for screws in your drive cages. You sandwich the cooler in between two drives, one mounted normally and one mounted upside down. Normal cases don't have screw holes in the right place to do this, so you have to either have a Koolance case or drill your own.
I had some mold/mildew growth in the 602 system. Despite repeated flushes, I could never get it totally out of there, it was pretty annoying. So far (3 months), I haven't seem anything similar in the Exos, so I'm assuming they've improved their cooling solution to make it less hospitable. By this time I was having a fairly severe mold problem on the 602.
Overall, these are pretty expensive, and you should consider the waterblocks a sunk cost, but the cooling system itself is likely to last through a couple of systems, as long as you keep the water clean. It's quiet, well engineered, and something you can mostly forget about.
I think my only real criticism of this generation is that it's hard to get the Exos filled full enough so that it doesn't make any noise. The fill point is now on top (I gather it used to be on the bottom), and getting it full enough to be completely silent is annoyingly difficult... I had to tip it up at about a 45 degree angle and use a turkey baster to get the last of the water in to silence it entirely. Maybe I'm just being stupid, but I didn't see any other way to do it.
Other than that, the Exos AL is an excellent product.... solid, well-engineered Water Cooling for Dummies.
I forget where it is, but there's a setting you have to change under XP to be able to use NTFS on a potentially removable device. I think it might be properties on the disk itself... there's some kind of checkbox that's related somehow to 'optimize for removable'.
From what I gathered at the time (and I'm sorry I'm not clearer about remembering where it is), NTFS requires a lot of write caching to work properly, and thus Windows by default refuses to format removable drives NTFS. But keep in mind that if you do this, you MUST stop the drive with the Safely Remove Hardware applet. You CANNOT just pull it, or you'll probably corrupt it.
I don't know if this will also let you partition it, but it's worth a try...?
Nothing inspires fresh thoughts like sealing the envelope. I forgot to mention that once you have selected the context for a device, you get four pages' worth of programmable LCD buttons for that device. (there's a Page key, non programmable). So you don't have just 10 buttons, you in essence have 40, 10 at a time, per device. If you have a very complex gizmo, you can assign it more contexts.
There's also a special FAV button, which goes to a pseudo-context... you have four pages of LCD buttons, but the main buttons stay in the 'default' context. This is intended for use with system macros. The default comes with a bunch of channels listed, and macros to change to those channels, but of course you can do anything you like.
If it didn't come through strongly enough in the parent post, I LOVE these units. They are extremely well-designed, and a real pleasure to use.
I bought an MX800 for myself and was so impressed, I bought an MX700 for my mom for her birthday. She's happy as a clam with it!
These are fantastic remotes. Every button is learnable, programmable, and macroable. There are 10 special buttons up on top, with LCD labels next to them which you can change.
The default model is to have each of the 10 main buttons correspond to a 'device'; when you press that device's button, the remote changes context. The 10 buttons up on top now become entirely programmable to do whatever you want, and the rest of the hard buttons can take on any function you wish. The remote offers either 16 or 20 'devices', which gives you, in essence, 16 or 20 separate controllers.
The easy/normal method is to specify all the devices you own; there's a large database of devices built into the programming software. You can also import learned codes from files that other users have created (www.remotecentral.com has many many files available), or even import Pronto.ccf files. If there are no codes for your device, you'll have to learn them into the remote. But you only have to do this once... unlike most remotes, the HTM will never forget what you load into it, even if you take the batteries out. Plus, you have a backup on your computer to boot, which will let you program as many remotes as you like with the same configuration. (if you're in a big house, say, and you want several remotes, any of which can control anything in your house.)
Once you have specified your devices and learned the codes you need, you can then shortcut buttons to any of the other codes, even on other devices. The software lets you "punch-through" some buttons, like volume, channel controls, and play/stop buttons, so that pressing them will always send codes to a specific device. This built-in punch through is a nice timesaver, but I found that it didn't cover everything... I myself ended up manually linking a number of codes around. It's very easy to do. Punch-through is a convenience feature, but if it doesn't do things exactly how you like, you can just ignore it and set every button up in every context to do anything you want.
The main difference between the 700 and the 800 is that the 800 offers an RF link to a slave RF/IR transcoder. You plug in the slave near your AV gear. It has connections for up to six little IR blasters on fairly long wires, which you attach to the IR sensors of your gear. The MX800 will then send RF commands to the slave unit, which will then echo them to the correct target device. You can have multiple slave units and set up routing of commands so that you can control multiple rooms/zones from one controller, anywhere in your house. The MX700 is IR-only, but is otherwise identical.
Both units offer very, VERY powerful IR transmitters... they're so powerful that precise aim seems to be totally unnecessary. As long as you're in the same room, it doesn't even seem to be necessary to actually point the remote at your equipment.
I do have a few quibbles with them, but nothing huge. The biggest thing is that I wish the LCD labels had one more letter; the LCD labels for your upper 10 buttons are only 7 characters. 8 would be easier, and 10 would be about ideal. it's hard to abbreviate properly in only 7 characters.
You MUST program these units with a computer. If you have a laptop, that's easiest, as you can sit in the front room with your other remotes and program it, but you can walk back and forth from a PC in the other room if you need to. (you have to have the remotes on hand while connected to the computer to do memorization, as far as I can see.) They come with the serial cable you need... you will need a standard 9-pin serial port. If you're on a Mac, I think you're SOL... the cable is PC-standard, and the software is Windows-only. You might be able to get it running with a USB->serial interface and emulation software, but it'd be a PITA.
In 1984, we were sure Apple would wreck IBM. They told us so in the Superbowl!
In 1994, we were sure that IBM would wreck Apple.
In 2004, we now realize that we were smarter 20 years ago than 10.:-)
(and yes, I realize that IBM isn't 'wrecked', but it is very, very amusing that the ever-dying Apple outlasted IBM in the personal computer market.:) )
What happens with me is that I put the machine into hibernation, and when I wake it up, it freezes just after loading the hibernation file from disk. Once a given hibernation file freezes, it will ALWAYS freeze, without fail. The only way to recover the laptop is a normal boot, at which point it works fine.
One weird thing that I have noticed is that running Firefox is closely linked to the chance of failure to come out of hibernation. If I close ALL programs before hibernating, it always comes back up. If Firefox is running, it'll fail to come back up about 20% of the time.
I haven't tested extensively to see if it's ONLY Firefox that can cause this issue. That's my main use for that old laptop anyway, web browsing. Once I realized the cause of the problem, I started closing all programs before hibernating, and now it seems to work fine. I haven't had a hibernation recovery failure for a long time.
"designed to start yet another GPL flamewar" -- oh please. I was expressing an opinion, and quite gently. I have never before been banned from any public discussion forum, under any alias.
Normally, I would go read what I wrote to be certain that my memory of events and of what I said is correct, but, gee, I can't read it anymore. It never occurred to me that you'd actually ban me for a dissenting opinion, so I didn't save a copy.
If any bystarnders are actually looking, I suggest you go read some of the many hundreds of posts I've made over the many years I've been here. I'm not a troll. I think about what I say before I say it. I make no pretense of perfection, but go read some of what I've written, and think to yourself about whether that person would be likely to start a flamewar. I'm pushing 40, for chrissake. I have better things to do.
Contrast that with the numerous people talking about the abuses perpetrated by Sveasoft. There's an awful lot of smoke here. Perhaps, just perhaps, there's a fire?
James is very, very good at sounding reasonable, but behind that reasonable facade lurks a very nasty fellow indeed. Read some of the stuff at the link above for some examples.
And James... nobody is begrudging you making money on your project. At least, it sure doesn't sound like they are. I know I don't care... make all the money you like. And I pay for quite a bit of the free software I particularly like... send wishlist gifts, that kind of thing. I had no interest in shutting down your project. If anything, I wanted to help it.
I, for one, just don't think that your glue work is any more valuable than the work of all the people who came before you. I'm cheerfully willing to help subsidize that kind of effort. I am not, however, happy about seeing GPL code hijacked. Thousands of programmers have put in millions of hours to make your project possible, and you are in essence spitting on them. Shame on you.
Even a two week delay, by the way, is unacceptable under the terms of the GPL. And when I posted my message, it had been more than a month and closer to six weeks. I'd have to check my post to be sure, but I'm nearly certain that it was this time delay that I found pretty questionable.
Again, to the world at large.... I'd suggest spending your money elsewhere. Support projects with ethical leaders. False DMCA notices and falsified hack reports, if true, are way, way, WAY into unacceptable behavior, and shouldn't be supported.
They're kind of expensive, but a Soekris box could work well for you. They are veyr small, fanless PCs without video cards, which use Compact Flash as their hard drives. Their fastest machine is a 266mhz 586-equivalent, which is fast enough to route 10-20 megabits, depending on how much processing you're doing per packet. They all have multiple Ethernet ports, and the various models come with different mixes of PCMCIA, mini-PCI, and 3.3v full-sized PCI slots.
Note that getting a pseudo-embedded environment like this running properly is not trivial. Since there are no hard or floppy drives, you must either install the CF, netboot the unit, and install an OS image, or else build an OS image from another computer and plug it in. And because CF has limited write lifetime, you have to be very careful to minimize writes.
But, once you have things working, these little boxes make surprisingly effective routers and firewalls. They are totally silent and have no moving parts, which makes them good for hard-to-reach installations like tower tops and such.
The main downside is the cost... with a CF, you can expect to put about $300 into a 4801, which is way more expensive than a Linksys box. But you have full control... except for having no video card, they're pretty much like any other PC you'll ever work with.
Sveasoft is very, very abusive of the GPL. You might want one of the other firmwares, like OpenWRT.
Basically, if you exercise your right ot distribute under the GPL, you lose your right to download further beta firmware releases. I figured I could live with this, but it gets worse. A) he doesn't release the source code for quite some time after releasing a given binary, and B) you can't complain about this in any way, shape, or form, or he will terminate your account. I had posted what I thought was a pretty gentle reminder that thousands of people have written millions of lines of code so that he could do his simple (in relation) glue work, and that he should consider GPL redistribution as advertising. I got a short email notice to the effect of 'Copying my software is PIRACY, not advertising!' and a cancellation notice. Note that at NO time did I exercise my GPL right to redistribute. I was terminated simply for having an opinion he didn't like. He did, at least, refund my $20.
But it gets worse still... it appears he has gone to amazing lengths to get mirrors shut down. He may have finally given up on this, but at least one person here on/. claims that he has made false hacking claims and has issued false DMCA takedown notices. Lots and lots of detail here.
I strongly suggest that you choose another firmware. If it's not as good as you want it to be, help to make it better, instead of lining the pockets of this guy who hates the GPL, but is more than willing to take advantage of it.
There was a bug in Cstrike recently where if someone changed their name to include a " %n ", it would immediately crash the server and all the clients. They rolled out the fix sometime Monday, I think.
About Wednesday, one of the players on the server I was on changed his name to include a %n. This blew away about half the people on the server. Why? Because the pirates didn't have the fixed version yet.
As long as he sat there with the %n, nobody with a pirated game could logon, and the 40-person server was unable to climb above about 24 people. Normally, it's at 40 players 95% of the time.
Pirated Counterstrike, in other words, is extremely, extremely common. I don't know if it's deliberate on Valve's part, but they don't seem to be doing a good job AT ALL of shutting out the thieves. One thought that comes to mind is that maybe they're trying to get online 'buzz' early on, by making sure there are lots of Cstrike players. Perhaps they'll get more aggressive about shutting down pirates once the game hits store shelves.
But, it is also possible that they CAN'T for some reason... which, if true, doesn't encourage me that they'll get CS:S terribly cheat-free.
Looked like about 50-60% pirated copies on the server I was on. Real shame.
Actually, you should make a spelling mistake when correcting grammar, and a grammar mistake when correcting spelling. That way, ALL the nazis leap in and great flamage ensues.
Slashdot really does seem to ignore error reports.... I have seen typos and problems on numerous occasions, and have reported them, and I don't think I have EVER seen a story change in ANY way from preview to release. Well, ok, I saw a broken link get fixed once, so I've seen it one time. But that was it; no spelling corrections, no summary fixes when the submitter got it completely wrong.
They also seem to refuse stories with Coral cache links. Apparently, making sure a small site doesn't get slashdotted is no good.
I, for one, am tired of seeing my subscription dollars go to this kind of poor effort. I haven't seen Slashdot really change or grow or improve for the last four years... their 'sections' are the 'big improvement', when really it's just the same old crap in ugly colored boxes. None of the other problems have been fixed; there are still dupes, the search is largely useless [can't even search on multiple keywords properly!], the editorial standards are low, and they actively defend their policy of DoSing small sites. [which is the proverbial straw for me, they've had YEARS to figure this problem out.] And the site's not very reliable. It's down a lot. Always briefly, but I get error messages (often 550 Service Unavailables) very frequently.
In 1998, this was pretty acceptable, but they've been a 'pro' site for years now. Asking for subscription money implies, I think, a higher standard. I have subscribed since they started subscriptions, and have given them quite a bit of money. But when my subscription lapses this time, no more, unless and until they show signs of actually improving again.... of actually caring. I can think of much better ways to waste money.
Yeah, I know this is -1 Offtopic, but it's worth some karma points to vent a little.
Well, if that is indeed the case, then we should let the Hubble die. It's dumb to waste money doing something in orbit if we can truly do it better and cheaper from the ground. If we really do get more science spending the money on the ground, then spend it there... that's just sensible.
I don't think the risk to the astronauts, however, is a particularly compelling argument. They know the risks in going up, maybe better than anyone. Perfect safety is appallingly expensive; if we can just do 'good safety' or even 'tolerable safety', we'll probably still have people lining up a thousand at a time to participate. Our absolute obsession on astronaut safety is laudable, but it gets to the point of being self-defeating. If we make it too expensive to go into space, then we will never get there.
Pioneers have always accepted greater danger in exchange for the thrill of exploration. I don't think the astronaut program is any different. If you went and asked the astronauts if they'd take a mission that was half as safe as what they usually run, but was guaranteed to happen, I'll bet virtually all of them would sign up.
Well, you have to realize, the Hubble is very, very old technology. It was actually completed in 1985, although it wasn't launched until 1990, because of the Challenger disaster.
With that TWENTY YEAR OLD technology, we have gotten absolutely amazing results, as you have seen. After two decades of advancement, we can do even better from the ground, but that doesn't invalidate the science we have already done. (like that huge meteor strike on Jupiter; because of the Hubble, we practically had front-row seats). The money involved to keep Hubble running isn't that large, relatively speaking; the initial build and launch were very expensive, but we have already paid for those. Fixing the Hubble just needs to be cheaper than building a ground-based 'scope of similar quality, and I don't think there's any argument about that. And even if the Arizona telescope is better, that hardly makes the Hubble useless. There's never enough observation time for everyone on the really big instruments, and having several available would be good.
The Hubble's successor should be as far past its ground-based competition as the Hubble was. Like it or not, that atmosphere is annoying: we can correct for its presence to some degree (which we couldn't twenty years ago), but it's even better to not have it in the way. We're trying to look unbelievably far away, and if we're not spending a great deal of time correcting for the atmosphere, we can spend time correcting for much smaller problems.... ultimately giving us far better pictures.
Reemember the Hubble Deep Field -- in the darkest part of the sky, in an area about as large as a grain of sand held at arm's length, we saw at least 1,500 GALAXIES.
Slashdot Mirror
The Apple //e and //c spelled it that way, with two slashes. As far as I can tell, the Apple 2 series never used Roman numerals. The Apple 3 may have.
In real life, of course, 2, II, //, ][... were all perfectly acceptable. Everyone knew what you were talking about, and I don't think anyone cared which version you used.
Both the physical case and the ROM in the machine said Apple ][. Not 2, not II, but ][.
Offhand, I suspect that's pretty authoritative.
One thing that people don't often mention is that, while the lag was getting pretty terrible, the game was still mostly playable. It might take several minutes(!) for an Auction House query to return, or for an auction to be created, or for your email to show up, but the transactions DID eventually happen.
:-)
Instead of just blowing up completely, by and large, WOW fails fairly gracefully. The engineering in that is non-trivial. I don't think people realize just how good that code is. Getting a system that stays reasonably stable under completely untested loads is really, really hard. I am VERY impressed with the quality of their design and code work.
And, yes, some data did get lost... the servers did eventually seize up and crash completely, and often there'd be some data lost. But, at least in my case, it was never much more than a skill point or two, or a few hundred experience.... twenty minutes of lost playtime. I'm sure some people had a worse experience than I did, that's the nature of random data loss, but I wasn't badly affected.
When you consider the sheer scale of what they're doing.... they had TWO HUNDRED THOUDAND PEOPLE AT ONCE playing their game not long ago. The scale of that just boggles the imagination. If you assume 32kbits/second down, and 2kbits up (probably a bit skinny, but I'll try to err against Blizzard here), that's an aggregate total of 10,880,000,000 bits per second. Roughly 10 gigabits, or total saturation of an OC-192. Just the FIREWALLING on that kind of traffic is a HUGE project! Admittedly, they've broken that up into 3 or 4 datacenters, but doing firewalling and connection tracking on a mere 2.5gigabits is still pretty daunting. And that is completely ignoring the application servers, the load balancing, the inter-server communication, the databases..... just 1% of this project is a HUGE BIG DEAL.
The fact that we were able to pile in there at that kind of speed and the game didn't seize up and die completely is a resounding, amazing success. I'm sure the Blizzard guys aren't feeling too great about how things went by now, but.... guys, you kicked ASS. You did somethiung that has never been done before, a level of complexity nobody else has ever reached, got loaded down with about four times as much traffic as you were expecting.... and STILL mostly succeeded.
I have every faith that you'll work out the remaining kinks and bottlenecks.
By the way, the last couple days, on Uther, have been quite good... I think I got one disconnect in two days, and there really hasn't been any lag. They may nearly have the problems fixed. I haven't been thinking about bugs, just about slaughtering beasties.
Wow, a front page article on Slashdot that amounts to, "gee, how do I build a server?" Spiffed up a bit with trendy, techie-sounding words, but cripes. This is FP news-worthy?
That said... if all you're doing is file serving, a tiny machine by modern standards is fine. 64 megs of ram in a P3/400 would make a very solid home server. If you want to use software RAID, though, it's a good idea to go faster... you'd want at least 1ghz for that, maybe 2, depending on how much traffic you were sending to the box and how patient/impatient you are.
Since it's going in your basement and you have no worries about size or noise levels, get a big whompin' case with lots of 5.25" slots. Cremax makes some nice enclosures that will let you put 5 3.5" drives into 3 5.25" bays, with good fans for cooling. They have multiple variants. I'm using the SCSI flavor, but you can get them in SATA too (and IDE, I think, but I'm less sure about that.)
I have an older 3ware 8500 RAID card, and it's dismally slow at RAID 5, even though it's supposedly 'optimized' for it. I don't know if the newer SATA versions are better, but while they are well-supported in Linux, and, being hardware RAID, are a total no-brainer from an admin perspective, my generation of cards was horribly, horribly slow. I get at least four times the performance using Software RAID on an Athlon 1900+.
This is how my network server looks:
Big case;
400W PC Power and Cooling power supply;
ASUS A7V333 motherboard;
Athlon 1900+, I think just 266mhz FSB (not sure);
1 gig of RAM (nice for caching, not at all necessary to have this much);
Ancient video card, Matrox Milllenium 2, I think;
3com 3c509 network card;
ICP Vortex 32-bit RAID controller, bought used. The first one I got was dead... had to replace it. I got it pretty cheap, intending it for another project that fell through, and so I ended up using it at home instead. I think it was about $100, but I'm not sure now. These boards KICK ASS. Great linux support, VERY fast. Awesome hardware.
6 18-gig 10KRPM SCSI drives; machine boots from this array, and Debian is installed here;
2 Cremax 5-in-3 SCSI enclosures;
1 3ware 8500+, in JBOD mode (software RAID is WAY faster);
4 80 gig IDE drives (small, but I set this part of the system up a long time ago)
The SCSI array is damn fast, an excellent spot for interactive, disk-intensive things like IMAP or big compiles, while the slower IDE array is ideal for filesharing.
You should be able to set up a similar system for, oh, $1500? And keep in mind... this is HUGE overkill for a home network, it would be a solid backbone for a company up to about 50 people... though it might need more drive space, and I'd probably want redundant power supplies in a really central machine. You could run mail, internal DNS, DHCP, a squid proxy, internal webserver, and Samba for that many people without it even working that hard.
File sharing is fundamentally a tremendously simple thing, and it just hardly takes anything at all to do a perfectly fine job. Once upon a time this was akin to rocket science, but at this point, even a garbage $200 PC from Walmart would probably be an okay fileserver.
Again: the specs on the machine above are wild overkill... swatting a fly with a sledgehammer. But if you want to spend that much money, or you have most of the parts laying around the house anyway, it'll do a damn good job.
You just don't get what this MEANS. You're parroting what the kernel devs are saying, without truly thinking about it. They apparently aren't really thinking about it either.
.sort of waving their hands in the air and expecting that other people will make their broken software suck less. This is an enormous change, and it benefits NOBODY but them. Ultimately, it doesn't even benefit them, because eventually it's going to slow or even stop Linux adoption.
Point 1: What they are saying with this model is that they want to do all the fun stuff, not the bug fixing..
Point 2: If Linus' "stable" tree isn't guaranteed to be as stable as he can possibly make it, then we're going to end up with DOZENS of different 'stable' kernels, all of which are slightly different. We already have that problem, but this is going to make it much worse. All the different distros are going to be solving the same problems, but many of them are going to come up with DIFFERENT SOLUTIONS. And, being human, many of these guys will believe that THEIR way is the best, and that the solutions the OTHER companies came up with are inferior.
So as a Serious, High-End Program Vendor, like Oracle, who is comitted to supporting Linux, I'm now forced to ask, "Which Linux? Red Hat? Suse? Novell? Debian?" They alreayd have to do this to some degree, but now they get a whole extra level of complexity... do we support 2.6.7 only? Do we certify multiple kernels? If we choose more than a couple of kernels across maybe two distros, our test load will become unmanageable.
Point 3: There IS NO MORE ONE TRUE LINUX. Always before, there has been a core, stable kernel, at which you could point a finger and say with authority, "THIS IS LINUX", and be right. If you write something that works with the One True Linux, and then it doesn't work with Mandrake or Red Hat or what have you, then you have a very clear and obvious point of approach to get it fixed. And they can't waffle... if it works with One True Linux and not with their product, then they are at fault. That simple.
Instead, what we're ending up with here is finger-pointing... it works on Red Hat, but not on vanilla Linux, and it kind of works on Mandrake but acts funny on Tuesday, and it erases Debian systems completely. Who's to blame here? WHO KNOWS?! There's no One True Linux to test agaist. The kernel devs will point at the distributions to make broken things work... the distributions will point at the kernel devs, and end users are going to start pointing to Windows and the BSDs.
If I were a serious developer, I'd look at that operating system model and run in terror. Oracle must be kicking themselves bigtime for such a huge commmitment to a platform that is suddenly disintegrating underneath them.
Without a rock-stable center, there IS NO LINUX, it's just a bunch of semi-compatible custom forks. It's UNIX all over again!
This is an absolute disaster on every front but one.. the kernel developers get to have more fun and spend less of that icky bugfixing time. Yay. Go team.
I am seriously looking at that. I thought about adding it into the original post, but the inevitable reaction would be 'don't let the door hit you in the ass on the way out'. I have a lot of inertia with regard to Linux, as I'm very used to it and have been for ten years, but if the development process doesn't go back to the old model (or something like it) soon, my annoyance is likely to exceed my inertia.
Linux, at the moment, OWNS the words "secure and "reliable" in the marketplace. Once it loses that reputation, it will probably never again own them. Every day that the development process continues in the present mode, Linux's credibility is damaged. Once it goes past a certain point, the damage will be unrecoverable, even if the software returns to its original quality. The world thinks that if something is free it must suck. The present development model will confirm that belief... and once people realize that their suspicions were correct all along, they'll NEVER AGAIN change their minds.
Developers: the other operating systems are NOT STANDING STILL. Microsoft gets better every day. FreeBSD has enough features to be a useful desktop, and makes an excellent server. Linux has huge momentum, but if you don't stop this developer-focused insanity, they are going to make you irrelevant.
The real world wants things that WORK, not feature-laden piles of crap that don't run right.
I can't find the exact quote in a quick google search, but as I recall, one of Linus' main reasons to write Linux was because hardware is very reliable... and there's no reason software shouldn't be just as good.
Have we forgotten so quickly? Is it really about features now, and not rock-solid stability?
As far as I can see, the testing on Linux is "write a bunch of code and toss it out where the suck, er, end users can test it." Back when this was all in the development code, it was okay. Putting out the current piles of smoking garbage in the "stable" tree, on the other hand, is not.
Your example PROVES the point. Go to 2.7 and play in your sandbox. Do all the free work you like in the development branch. That process has worked for 10 years.
This new model, on the other hand, benefits almost nobody.
If I'm running 2.6.8, and a new bug comes out, I'm forced to either A) upgrade to the most recent 'stable' kernel, introducing new features about which I know nothing, and which themselves may be security problems, or B) can hope that someone will backport the security fixes to the kernel version I'm running. I don't know enough about kernel development to patch it myself, but I can no longer just drop in the most recent stable kernel and expect it to work unchanged.
A sysadmin's most precious commodities are time and attention. With this new development model, suddenly I am forced to either pay a great deal of attention (and a great deal of time) to each and every version of the Linux kernel, or I need to pay a vendor to do it for me.
The kernel developers are, in my opinion, shirking their single most fundamental duty... to ship a stable, secure product. Suddenly, because it's easier for them, they have abrogated the fundamental contract, that they will write great software. (buggy, insecure software is not great, no matter how many features it has.) They just wave their hands vaguely in the air and say tha the distributions will take care of those problems.
Guys, it's not gonna happen. The way you get stable software is by not adding features. In your case, by branching off to 2.7, and letting us beat the unchanging (except for bugfixes) 2.6 tree to death. If you keep adding features, you keep adding bugs. That's how it works.
You had this NAILED for years and years... there is a huge community that has built up around the fundamental social contract that even numbered kernels are as stable and secure as you know how to make them, and the odd-numbered branches are the home for new code and new features. Changing that contract simply becuase it makes your lives mildly easier is a hugely destructive idea. You may save yourselves a bit of work, but you create an enormous amount of it for everyone else.
Ted T'So said:
In other words, he thinks it's perfectly fine if only 1 out of 3 'stable' kernels are actually stable.This is not acceptable.
You can bet that Bill has a big grin on his face about this one. If I want new features with my security fixes, I might as well choose Microsoft and their service packs.
Heck, they even have a QA team!
You, sir, are out of your mind. Some people are stupid, therefore all complexity is to be removed. You make vague generalities about how some people somewhere (no actual proof, mind you) blew it on ACLs, so ACLs are bad. Argument by assertion is not proof.
A good ACL system is more powerful, more flexible, and conceptually one heck of a lot easier than the very primitive Unix permissions. The Byzantine workarounds required to implement a truly complex permissions setup in Unix make it far, FAR easier to make mistakes.
If we grant your assertion that people are stupid, then a very precise permissions system is much to be desired, since there is far more of a chance to make a bad mistake mapping a knotty permissions problem onto the simplistic Unix design.
Like it or not, some people NEED complex permissions sets. Unix wasn't designed the way it was designed 'to be secure', Unix was designed the way it was because that's ALL THEY THOUGHT THEY NEEDED THIRTY YEARS AGO.
There's a REASON groups like the NSA are pushing the complex permission structures like SELinux... it's because what we have now is grossly inadequate. Just as the Unixy OSes don't have the language to describe precisely enough what sorts of permissions programs should have, the Unixy filesystems (mostly) don't have permissions structures that easily cover real-world scenarios.
ACLs have that power, and just because some people use them badly is no reason to dismiss them. In the real world, they WORK BETTER.
A well-designed ACL system is leaps and bounds better than Unix permissions. The problem is mostly that people implement ACLS very, very poorly, scattering permissions all over the filesystem where they are hard to find.
Microsoft has been doing this right for a long time, and they were pushing the AGLP standard in the NT 4.0 days (the last Windows I truly administered in a very complex environment.) AGLP means:
A)ccounts go in G)lobal groups; (the ones on your domain controller)
Global groups go in L)ocal groups; (the ones sitting on your fileservers)
Local groups get P)ermissions. (the actual filesystems)
How this translated for me was this:
Global groups, ones on the domain controller, specify GROUPS OF PEOPLE;
Local groups, ones on physical servers, describe SETS OF PERMISSIONS
(at least) three groups are made for each share on a server: Share RO, Share RW, Share Admin. Additional Local groups might be needed if you had weird permissions requirements, but I never did.
Permissions are assigned ONCE EVER to the filesystem, children inheriting from their parents.
So, when you're building a server, you decide what shares you want. You create 3 groups for each share, and assign the correct rights to each group on each share. You then load Domain groups into your local groups. If I'm building a machine for Accounting, I might put the "Accounting Staff" domain group in the "Accounting Share RW" local group. I'd probably put the Domain group of "Accounting Managers" (even if there was only one manager, I'd still name it plural and put him in it) into "Accounting Share Admin" group. And I might put the "Upper Management" domain group in the RO group.
You just always, always stick with this standard. If you need a specific person to have specific access to a specific share, you *create a special domain group for them*. If you can't think of anything better, perhaps "People with RO Access to Accounting Share". You then put that group in the server's local group. From then on, if you need to give that specific permission to others, you just stick them in that special Domain group. Note that it's better to have Global groups be more functional descriptions rather than permissions descriptions, but no model handles 100% of all possible permissions weirdness perfectly.
By creating sensible groups at the Domain level, and putting individual accounts in the proper Domain groups, you remove all need to EVER change permission on files. You don't ever, ever have to touch a filesystem again to change permissions, assuming you were sufficiently granular with your Local groups and filesystem permissions to begin with. You can manage literally MILLIONS OF FILES with just a few clicks in User Manager. What used to take hours (reassigning permissions on a zillion files) now takes only seconds... just swapping people into and out of groups. (or, perhaps, swapping Global groups in and out of Local groups.)
NT's ACL system, in other words, can let you abstract your information policy, even make it somewhat visual, so that at each level you're only dealing one thing. You can make vast, sweeping security policy changes with just a few clicks and WITHOUT BUGS.
(Note: there are some additions to this model that are necessitated by how Active Directory works, so don't take this as literal gospel. It's still a good model, but it needs some adjustment to work properly with AD. I'm not familiar enough with the specifics to tell you, but I know 2K has added a couple more group types, so it may require another level of abstraction.)
I haven't seen ANYTHING in Unix that will let me both have that kind of granularity and sweeping power.
Unix permissions, in other words, SUCK ROCKS. They're HORRIBLE. ACLS are both far more elegant and far more powerful.
I have a Koolance case, the PC-602 I think. It was one of the first they shipped, and I bought it for its silence, and MAN was I disappointed. It did a good job of cooling, but it was very loud.
Recently, I upgraded to an Athlon 64, and this time around I bought a Koolance Exos... I bought it with thirty feet of external tubing, figuring I'd put the cooler in the closet or in the next room -- behind a closed door. But for whatever reason, the Exos AL is a LOT quieter than the visually identical 602. It's so quiet, in fact, that I have never bothered moving the cooler into the closet... it sits on my desktop, and I can barely hear it. The G4 is much, much louder.
I'm cooling three hard drives, two WD Raptor 36gs and a WD 250 something or other, (the kind with extra cache, JB?), the motherboard chipset, an Athlon Mobile 3200+, and a GeForce 6800GT. I'm very pleased with how cool the hard drives run in particular... they put out a lot of heat, and the waterblocks + thermal goop do an extremely good job. They run just *slightly* warmer than room temperature.
I haven't tried overclocking... I figure I'll do that later instead of upgrading, when the machine starts to feel too slow. I suspect I've got a TON of headroom... even with all that stuff I'm cooling, I never get much above 37C. I suspect I'll be able to increase heat output quite a bit and stay comfortably cool. I actually bought it to be quiet, but it's nice to know that I can make it go fast too.
Upshot: the older cases WERE obnoxiously loud. The current Exos AL is VERY quiet. I assume any case you'd buy from them now would be similar.
Note that to use a hard drive cooling block on more than one hard drive, you need either the special Koolance cases or some way to drill custom holes for screws in your drive cages. You sandwich the cooler in between two drives, one mounted normally and one mounted upside down. Normal cases don't have screw holes in the right place to do this, so you have to either have a Koolance case or drill your own.
I had some mold/mildew growth in the 602 system. Despite repeated flushes, I could never get it totally out of there, it was pretty annoying. So far (3 months), I haven't seem anything similar in the Exos, so I'm assuming they've improved their cooling solution to make it less hospitable. By this time I was having a fairly severe mold problem on the 602.
Overall, these are pretty expensive, and you should consider the waterblocks a sunk cost, but the cooling system itself is likely to last through a couple of systems, as long as you keep the water clean. It's quiet, well engineered, and something you can mostly forget about.
I think my only real criticism of this generation is that it's hard to get the Exos filled full enough so that it doesn't make any noise. The fill point is now on top (I gather it used to be on the bottom), and getting it full enough to be completely silent is annoyingly difficult... I had to tip it up at about a 45 degree angle and use a turkey baster to get the last of the water in to silence it entirely. Maybe I'm just being stupid, but I didn't see any other way to do it.
Other than that, the Exos AL is an excellent product.... solid, well-engineered Water Cooling for Dummies.
I forget where it is, but there's a setting you have to change under XP to be able to use NTFS on a potentially removable device. I think it might be properties on the disk itself... there's some kind of checkbox that's related somehow to 'optimize for removable'.
From what I gathered at the time (and I'm sorry I'm not clearer about remembering where it is), NTFS requires a lot of write caching to work properly, and thus Windows by default refuses to format removable drives NTFS. But keep in mind that if you do this, you MUST stop the drive with the Safely Remove Hardware applet. You CANNOT just pull it, or you'll probably corrupt it.
I don't know if this will also let you partition it, but it's worth a try...?
Nothing inspires fresh thoughts like sealing the envelope. I forgot to mention that once you have selected the context for a device, you get four pages' worth of programmable LCD buttons for that device. (there's a Page key, non programmable). So you don't have just 10 buttons, you in essence have 40, 10 at a time, per device. If you have a very complex gizmo, you can assign it more contexts.
There's also a special FAV button, which goes to a pseudo-context... you have four pages of LCD buttons, but the main buttons stay in the 'default' context. This is intended for use with system macros. The default comes with a bunch of channels listed, and macros to change to those channels, but of course you can do anything you like.
If it didn't come through strongly enough in the parent post, I LOVE these units. They are extremely well-designed, and a real pleasure to use.
I bought an MX800 for myself and was so impressed, I bought an MX700 for my mom for her birthday. She's happy as a clam with it!
.ccf files. If there are no codes for your device, you'll have to learn them into the remote. But you only have to do this once... unlike most remotes, the HTM will never forget what you load into it, even if you take the batteries out. Plus, you have a backup on your computer to boot, which will let you program as many remotes as you like with the same configuration. (if you're in a big house, say, and you want several remotes, any of which can control anything in your house.)
These are fantastic remotes. Every button is learnable, programmable, and macroable. There are 10 special buttons up on top, with LCD labels next to them which you can change.
The default model is to have each of the 10 main buttons correspond to a 'device'; when you press that device's button, the remote changes context. The 10 buttons up on top now become entirely programmable to do whatever you want, and the rest of the hard buttons can take on any function you wish. The remote offers either 16 or 20 'devices', which gives you, in essence, 16 or 20 separate controllers.
The easy/normal method is to specify all the devices you own; there's a large database of devices built into the programming software. You can also import learned codes from files that other users have created (www.remotecentral.com has many many files available), or even import Pronto
Once you have specified your devices and learned the codes you need, you can then shortcut buttons to any of the other codes, even on other devices. The software lets you "punch-through" some buttons, like volume, channel controls, and play/stop buttons, so that pressing them will always send codes to a specific device. This built-in punch through is a nice timesaver, but I found that it didn't cover everything... I myself ended up manually linking a number of codes around. It's very easy to do. Punch-through is a convenience feature, but if it doesn't do things exactly how you like, you can just ignore it and set every button up in every context to do anything you want.
The main difference between the 700 and the 800 is that the 800 offers an RF link to a slave RF/IR transcoder. You plug in the slave near your AV gear. It has connections for up to six little IR blasters on fairly long wires, which you attach to the IR sensors of your gear. The MX800 will then send RF commands to the slave unit, which will then echo them to the correct target device. You can have multiple slave units and set up routing of commands so that you can control multiple rooms/zones from one controller, anywhere in your house. The MX700 is IR-only, but is otherwise identical.
Both units offer very, VERY powerful IR transmitters... they're so powerful that precise aim seems to be totally unnecessary. As long as you're in the same room, it doesn't even seem to be necessary to actually point the remote at your equipment.
I do have a few quibbles with them, but nothing huge. The biggest thing is that I wish the LCD labels had one more letter; the LCD labels for your upper 10 buttons are only 7 characters. 8 would be easier, and 10 would be about ideal. it's hard to abbreviate properly in only 7 characters.
You MUST program these units with a computer. If you have a laptop, that's easiest, as you can sit in the front room with your other remotes and program it, but you can walk back and forth from a PC in the other room if you need to. (you have to have the remotes on hand while connected to the computer to do memorization, as far as I can see.) They come with the serial cable you need... you will need a standard 9-pin serial port. If you're on a Mac, I think you're SOL... the cable is PC-standard, and the software is Windows-only. You might be able to get it running with a USB->serial interface and emulation software, but it'd be a PITA.
Also note that you really want to go
In 1984, we were sure Apple would wreck IBM. They told us so in the Superbowl!
:-)
:) )
In 1994, we were sure that IBM would wreck Apple.
In 2004, we now realize that we were smarter 20 years ago than 10.
(and yes, I realize that IBM isn't 'wrecked', but it is very, very amusing that the ever-dying Apple outlasted IBM in the personal computer market.
What happens with me is that I put the machine into hibernation, and when I wake it up, it freezes just after loading the hibernation file from disk. Once a given hibernation file freezes, it will ALWAYS freeze, without fail. The only way to recover the laptop is a normal boot, at which point it works fine.
One weird thing that I have noticed is that running Firefox is closely linked to the chance of failure to come out of hibernation. If I close ALL programs before hibernating, it always comes back up. If Firefox is running, it'll fail to come back up about 20% of the time.
I haven't tested extensively to see if it's ONLY Firefox that can cause this issue. That's my main use for that old laptop anyway, web browsing. Once I realized the cause of the problem, I started closing all programs before hibernating, and now it seems to work fine. I haven't had a hibernation recovery failure for a long time.
"designed to start yet another GPL flamewar" -- oh please. I was expressing an opinion, and quite gently. I have never before been banned from any public discussion forum, under any alias.
Normally, I would go read what I wrote to be certain that my memory of events and of what I said is correct, but, gee, I can't read it anymore. It never occurred to me that you'd actually ban me for a dissenting opinion, so I didn't save a copy.
If any bystarnders are actually looking, I suggest you go read some of the many hundreds of posts I've made over the many years I've been here. I'm not a troll. I think about what I say before I say it. I make no pretense of perfection, but go read some of what I've written, and think to yourself about whether that person would be likely to start a flamewar. I'm pushing 40, for chrissake. I have better things to do.
Contrast that with the numerous people talking about the abuses perpetrated by Sveasoft. There's an awful lot of smoke here. Perhaps, just perhaps, there's a fire?
James is very, very good at sounding reasonable, but behind that reasonable facade lurks a very nasty fellow indeed. Read some of the stuff at the link above for some examples.
And James... nobody is begrudging you making money on your project. At least, it sure doesn't sound like they are. I know I don't care... make all the money you like. And I pay for quite a bit of the free software I particularly like... send wishlist gifts, that kind of thing. I had no interest in shutting down your project. If anything, I wanted to help it.
I, for one, just don't think that your glue work is any more valuable than the work of all the people who came before you. I'm cheerfully willing to help subsidize that kind of effort. I am not, however, happy about seeing GPL code hijacked. Thousands of programmers have put in millions of hours to make your project possible, and you are in essence spitting on them. Shame on you.
Even a two week delay, by the way, is unacceptable under the terms of the GPL. And when I posted my message, it had been more than a month and closer to six weeks. I'd have to check my post to be sure, but I'm nearly certain that it was this time delay that I found pretty questionable.
Again, to the world at large.... I'd suggest spending your money elsewhere. Support projects with ethical leaders. False DMCA notices and falsified hack reports, if true, are way, way, WAY into unacceptable behavior, and shouldn't be supported.
They're kind of expensive, but a Soekris box could work well for you. They are veyr small, fanless PCs without video cards, which use Compact Flash as their hard drives. Their fastest machine is a 266mhz 586-equivalent, which is fast enough to route 10-20 megabits, depending on how much processing you're doing per packet. They all have multiple Ethernet ports, and the various models come with different mixes of PCMCIA, mini-PCI, and 3.3v full-sized PCI slots.
Note that getting a pseudo-embedded environment like this running properly is not trivial. Since there are no hard or floppy drives, you must either install the CF, netboot the unit, and install an OS image, or else build an OS image from another computer and plug it in. And because CF has limited write lifetime, you have to be very careful to minimize writes.
But, once you have things working, these little boxes make surprisingly effective routers and firewalls. They are totally silent and have no moving parts, which makes them good for hard-to-reach installations like tower tops and such.
The main downside is the cost... with a CF, you can expect to put about $300 into a 4801, which is way more expensive than a Linksys box. But you have full control... except for having no video card, they're pretty much like any other PC you'll ever work with.
Basically, if you exercise your right ot distribute under the GPL, you lose your right to download further beta firmware releases. I figured I could live with this, but it gets worse. A) he doesn't release the source code for quite some time after releasing a given binary, and B) you can't complain about this in any way, shape, or form, or he will terminate your account. I had posted what I thought was a pretty gentle reminder that thousands of people have written millions of lines of code so that he could do his simple (in relation) glue work, and that he should consider GPL redistribution as advertising. I got a short email notice to the effect of 'Copying my software is PIRACY, not advertising!' and a cancellation notice. Note that at NO time did I exercise my GPL right to redistribute. I was terminated simply for having an opinion he didn't like. He did, at least, refund my $20.
But it gets worse still... it appears he has gone to amazing lengths to get mirrors shut down. He may have finally given up on this, but at least one person here on /. claims that he has made false hacking claims and has issued false DMCA takedown notices. Lots and lots of detail here.
I strongly suggest that you choose another firmware. If it's not as good as you want it to be, help to make it better, instead of lining the pockets of this guy who hates the GPL, but is more than willing to take advantage of it.
I should have been clearer that this is Counterstrike:Source, which is not a free game. You must own Half Life 2 to play it.
They may have a point.
There was a bug in Cstrike recently where if someone changed their name to include a " %n ", it would immediately crash the server and all the clients. They rolled out the fix sometime Monday, I think.
About Wednesday, one of the players on the server I was on changed his name to include a %n. This blew away about half the people on the server. Why? Because the pirates didn't have the fixed version yet.
As long as he sat there with the %n, nobody with a pirated game could logon, and the 40-person server was unable to climb above about 24 people. Normally, it's at 40 players 95% of the time.
Pirated Counterstrike, in other words, is extremely, extremely common. I don't know if it's deliberate on Valve's part, but they don't seem to be doing a good job AT ALL of shutting out the thieves. One thought that comes to mind is that maybe they're trying to get online 'buzz' early on, by making sure there are lots of Cstrike players. Perhaps they'll get more aggressive about shutting down pirates once the game hits store shelves.
But, it is also possible that they CAN'T for some reason... which, if true, doesn't encourage me that they'll get CS:S terribly cheat-free.
Looked like about 50-60% pirated copies on the server I was on. Real shame.
Actually, you should make a spelling mistake when correcting grammar, and a grammar mistake when correcting spelling. That way, ALL the nazis leap in and great flamage ensues.
Slashdot really does seem to ignore error reports.... I have seen typos and problems on numerous occasions, and have reported them, and I don't think I have EVER seen a story change in ANY way from preview to release. Well, ok, I saw a broken link get fixed once, so I've seen it one time. But that was it; no spelling corrections, no summary fixes when the submitter got it completely wrong.
They also seem to refuse stories with Coral cache links. Apparently, making sure a small site doesn't get slashdotted is no good.
I, for one, am tired of seeing my subscription dollars go to this kind of poor effort. I haven't seen Slashdot really change or grow or improve for the last four years... their 'sections' are the 'big improvement', when really it's just the same old crap in ugly colored boxes. None of the other problems have been fixed; there are still dupes, the search is largely useless [can't even search on multiple keywords properly!], the editorial standards are low, and they actively defend their policy of DoSing small sites. [which is the proverbial straw for me, they've had YEARS to figure this problem out.] And the site's not very reliable. It's down a lot. Always briefly, but I get error messages (often 550 Service Unavailables) very frequently.
In 1998, this was pretty acceptable, but they've been a 'pro' site for years now. Asking for subscription money implies, I think, a higher standard. I have subscribed since they started subscriptions, and have given them quite a bit of money. But when my subscription lapses this time, no more, unless and until they show signs of actually improving again.... of actually caring. I can think of much better ways to waste money.
Yeah, I know this is -1 Offtopic, but it's worth some karma points to vent a little.
Well, if that is indeed the case, then we should let the Hubble die. It's dumb to waste money doing something in orbit if we can truly do it better and cheaper from the ground. If we really do get more science spending the money on the ground, then spend it there... that's just sensible.
I don't think the risk to the astronauts, however, is a particularly compelling argument. They know the risks in going up, maybe better than anyone. Perfect safety is appallingly expensive; if we can just do 'good safety' or even 'tolerable safety', we'll probably still have people lining up a thousand at a time to participate. Our absolute obsession on astronaut safety is laudable, but it gets to the point of being self-defeating. If we make it too expensive to go into space, then we will never get there.
Pioneers have always accepted greater danger in exchange for the thrill of exploration. I don't think the astronaut program is any different. If you went and asked the astronauts if they'd take a mission that was half as safe as what they usually run, but was guaranteed to happen, I'll bet virtually all of them would sign up.
Well, you have to realize, the Hubble is very, very old technology. It was actually completed in 1985, although it wasn't launched until 1990, because of the Challenger disaster.
With that TWENTY YEAR OLD technology, we have gotten absolutely amazing results, as you have seen. After two decades of advancement, we can do even better from the ground, but that doesn't invalidate the science we have already done. (like that huge meteor strike on Jupiter; because of the Hubble, we practically had front-row seats). The money involved to keep Hubble running isn't that large, relatively speaking; the initial build and launch were very expensive, but we have already paid for those. Fixing the Hubble just needs to be cheaper than building a ground-based 'scope of similar quality, and I don't think there's any argument about that. And even if the Arizona telescope is better, that hardly makes the Hubble useless. There's never enough observation time for everyone on the really big instruments, and having several available would be good.
The Hubble's successor should be as far past its ground-based competition as the Hubble was. Like it or not, that atmosphere is annoying: we can correct for its presence to some degree (which we couldn't twenty years ago), but it's even better to not have it in the way. We're trying to look unbelievably far away, and if we're not spending a great deal of time correcting for the atmosphere, we can spend time correcting for much smaller problems.... ultimately giving us far better pictures.
Reemember the Hubble Deep Field -- in the darkest part of the sky, in an area about as large as a grain of sand held at arm's length, we saw at least 1,500 GALAXIES.
There's a lot to see out there.