Republican commissioner Kevin Martin, who voted with the panel's two Democrats to shift authority from the federal government to the states, said the decisions "will have a direct impact on consumers." Mr. Martin added that the ruling would preserve lower, competitive phone rates and boost the availability of high-speed Internet access.
You'll note that more Democrats than Republicans supported this. *gasp* Democrats are owned by special interests too! Inconceivable!
But seriously, we could spend all day blaming one party or the other for this, or we could discuss the merits and problems of this new decision. Particularly interesting, to me, would be a description of the good things accomplished by the existing regulations. I was under the impression that the whole partial-deregulation quagmire was universally perceived as a disaster. Apparently you don't think it was. Why?
Why should they have to share? They invested all the money in laying down the lines. They spend all the money to keep them working and repair them if they get damaged. They employ the vast worker force required to do all the maintenance. They're responsible for building new lines and upgrading existing ones. So given that they're currently shouldering 100% of the initial investment costs and 98% of the maintenance costs, why on God's green earth are the telcos obliged to share?
What we should get out of this whole thing is real innovation and competition. Now that it's becoming increasingly difficult to be a successful DSL provider, maybe we'll start to see viable alternatives to cable and DSL. Wireless has real potential, if you can make it sufficiently low-cost and secure ("secure" in the sense of making it difficult for people to hijack).
Oh, and by the way, wherever there's a cable company there's competition. We get our phone service from our cable company here. The only monopoly is in the phone lines, so all you need to do is what the cable companies are doing (and doing very successfully): find an alternative to the phone lines.
(SoftUpdates aims to keep all file metadata consistent at all times; journalling aims to keep all file -data- consistent at all times.)
That's just not true. Soft updates works by ordering writes so that the metadata is always in a consistent state. This has the effect of also keeping the data in a consistent state, since data sits in the to-be-ordered queue right along with the metadata. Journaling filesystems typically track only the metadata (though some, like e3fs, can also do ordered data writes), which means that data can be lost as the metadata is returned to a consistent state.
JFS only logs operations on meta-data, so replaying the log only restores the consistency of structural relationships and resource allocation states within the file system. It does not log file data or recover this data to consistent state. Consequently, some file data may be lost or stale after recovery, and customers with a critical need for data consistency should use synchronous I/O.
The only benefit JFS has over UFS+SU in this context is faster on-crash fsck times. And it only takes about a minute to check a 60GB UFS filesystem after a crash, which is about 3 orders of magnitude better than e2fsck (I don't know how speedy jfs.fsck is in non-replay mode).
The chief benefit of JFS for FreeBSD is going to be portability. Which is a pretty big one, although I don't see JFS supplanting UFS before FreeBSD 6.0, if then.
I really don't like the BSD license 'cause I don't like to see my code on the Microsoft and folks hands and in another license!
Then don't use the BSDL. Some people and companies - Intel, in this case - care more about their standard (ACPI) being adopted than about their code remaining open source. In this case, it's in their interest to use as liberal a license as possible, and you don't get much freer than the BSDL.
You're seriously trying to base an argument around similarity of wording, without addressing the subjects of the arguments at all?!
First, often security holes are not immediately disclosed. The discoverer will instead contact the company responsible for fixing the holes and give them a certain amount of time to acknowledge, examine, and then fix the hole. Only if the company involved ignores the problem or doesn't fix it in a timely manner is the hole publicly revealed without a fix in-hand.
Second, there's an obvious difference here. If Apache has a security hole, eventually the Apache folks will release a patch that fixes it. Where's my patch from God that makes me immune to anthrax?
If you insist on looking at human security as similar to computer security, try this. Security by obscurity is only one part of the process, and probably the least important. We also buy off former Soviet scientists to keep them from defecting, keep careful tabs on the equipment needed to build all sorts of nasty stuff, use our intelligence to track groups which might have the capability of making WMDs, and all the rest. Obscurity is one small part of the Onion of Security.
I suspect the fact that the other player was a woman was a deliberate part of the social engineering behind getting her password. "Hi, I have this girlfriend, and she forgot her password but she's too embarrassed to call... yeah, you know how they are, in one ear and out the other..." and so on, playing on stereotypes of women being technically illiterate and generally ditzy.
I don't know if it happened that way, but it's certainly the first thing I'd try in his place.
Wasn't it the first mainstream compiler to include a complete DOS extender and feature full 32-bit support? I remember wanting it so badly in the DOS days, but I was a broke student and could barely afford the modem I used to download porn. I had to make do with Borland C++ (which was great, but lacked 32-bit support unless you felt like writing a lot of assembler).
Anyway, I'm excited by this because, well, competition is almost always a good thing. Hopefully gcc and Watcom can feed off each other and both products will improve. And perhaps more importantly for the build-everything users, another open source compiler might start moving people (like the developers of autoconf) to better support non-gcc compilers. This way, users who prefer Watcom's (or Intel's, or...) compiler can use it without as much tweaking.
The "64GB" options in the kernel just enable the page address extension (PAE), which is a way of addressing up to 64GB for the entire OS. So you can have 16 processes using 4GB each, and you'll be using all 64GB, but you can't have 8 processes using 8GB each.
It's not impossible to write an OS which lets each process access up to 64GB RAM, but it would be nontrivial. It would require many different segments and probably a lot of page faults. And it would be a lot of work, unless I'm missing something very obvious.
Performance is not the reason to go to 64-bit. The reason is the 64-bit address space, which allows individual processes to access 2^64 bytes of memory as a contiguous region. The IA32 ("x86") has a kludge which lets a system have up to 64GB RAM, but each segment can still only reference 4GB at most. If your operating system happens to use a flat memory model, like Linux does, this limits each process to 4GB total.
4GB is still a lot by any standard, but the problem is that the kernel, for example, needs to have some of its structures appear in the process's address space. Shared libraries also need to be in each process's address space, even if it's in memory only once. Even better, you need to leave room for the heap to grow as well as for user-loaded entities (like dlopen()'ed shared objects). In practice, I understand the default restriction for Linux is somewhere in the neighborhood of 1.5GB per process, though you can increase that to 3GB with some libc tweaks. There are a few kernel patches to raise that limit further to 3.5GB, but that's the absolute ceiling (and you are sacrificing what may be important things, like SysV shared memory segments).
Even now, it's not uncommon to see gaming machines with 1GB RAM or more. Even small servers will often have 4GB RAM. In a few years, the number of "high-memory" systems is only going to increase as advances in technology continue to drive down the cost of RAM and drive up the requirements of software. This is especially the case as databases become more important and commonplace in the business world. Everyone uses them now, but we can expect to see them used more often, and in more diverse places, than in the past.
There is also a hope among many of us that Intel and AMD will use this opportunity to create good chips, not just cheap ones. They have the opportunity to fix a lot of the stupid design decisions Intel made 20 years ago and put together a modern, clean system. Unfortunately, it doesn't look like this is going to happen (I don't think anyone at AMD has had an original idea in their entire lives, and Itanium is being designed by committee), but this is the hope. In short, we may not see any immediate performance gains, but in the long term, the design of the chips would enable faster improvements than we're getting with IA32s right now.
The problem is simple: the controls we have right now are far too coarse for the things we want to do with them. Running daemons as root is like putting out a match with a lake. They never need all the privileges of root. We need a way for root to drop its privileges selectively - or, better yet, a way to confer specific privileges to regular users. "The user apache can bind to port 80 without being root." "The user ftpd can chroot without being root." And so on.
It would also be lovely to see the tool which manages all this unify all the ACL-like aspects of the system into a single interface. Firewalls, filesystem ACLs, and privilege delegation are all remarkably similar, it'd be great to be able to define them selectively in groups (I think SELinux calls them "contexts") and confer them to various processes. Daemons can bind to ports, but not regular users? Easy: set the firewall ACL policy to deny, then grant the "daemon" context an exemption. Then tie in other useful privileges, like the ability to write to/var/run and send messages to syslogd. All these things are obviously related conceptually, but currently you'd need 3 tools to do it all (I don't think it's possible to regulate syslogd access this way, period, but I'm being optimistic and assuming it is).
Unfortunately, from what I saw of SELinux when I last used it, all this is some time off... especially the part where it's easy to administer and use. But to end on a positive note, there are a bunch of people who recognize this problem and are working hard to correct it.
Yeah, and there are still people who claim "back in the 70s, we didn't know smoking was bad for you." Anyone who's ever smoked knows it's bad for him. Anyone who's ever sat in front of a computer for 16 straight hours knows it's bad for him. You can just feel it, especially when you do it more.
The only possible explanation I can think of is that there's a lost of history-rewriting going on so we can get around the simple fact that people do a lot of stupid shit, knowing full well that it's stupid (and not caring). "Why did you smoke if you knew it was bad?" "Oh, I didn't know - the evil tobacco companies lied to me!" "Why did you sit in front of your computer for 16 hours a day?" "Nobody ever told me it was unhealthy!" Much better than the truth, which is often "I knew it was bad for me, I just didn't care."
A lot of you are missing the point. $10 million isn't that much. They could build 100 such machines for a billion dollars, not an unreasonable sum for the NSA, especially if it is spread out over a few years.
We aren't missing the point, you are. Encryption isn't perfect. It's good enough to discourage casual snoopers, and even some serious ones. But anyone who really wants to get at that decrypted information will be able to, no matter what keysize you use. If NSA thinks my email is important to national security, why wouldn't they just send over some guy to beat the shit out of me until I told them my passwords? I doubt that sort of thing costs them $10 million. Hell, even if they decide not to do that, for the low, low price of $1 million, I will voluntarily disclose all my personal information to whoever wants it.
It's pretty much analagous to all the various anti-theft things you can put on your car, ranging from a keyed ignition to a fuel pump cutoff. Anyone who really wants to steal your car is going to do it. The only purpose to all this anti-theft garbage is to make your car less convenient to steal than the cars next to it in the parking lot.
The time to start worrying about this sort of thing is when those computers cost $5000 and everybody can buy one and use it for evil.
The problem with your theory is that it doesn't really make sense from a business point of view. The goal of business is to make money, you're right on that. But Intel's not making any money (they actually are, but it's very, very little in comparison to pre-AMD years). A secondary concern is to get the stock price high to keep shareholders happy (since shareholders own the company). But with increased competition, decreased profit margins, and the slump in the tech market, Intel's stock has tanked practically to 20% of where it used to be.
If I were Intel's CEO, you'd better believe I'd go to bed hoping my researchers found some magic lamp that night. And if I were an Intel shareholder - which I am - I'd damn well want my company to take advantage of any competitive edge it found, especially improved technology.
Yeah, and you could implement a coarse kind of protected mode without all the CPU hardware to support it. But it's harder to do, and it's better when you have a two-tier approach where both the hardware and the software act as security barriers.
I'm not saying your point is without merit, but remember that the best security policies are built like onions, with many layers of redundant protection. Some of the features that are being talked about for the "Trusted Computing" initiative could be a useful and important part of a complete security policy (though I doubt their utility for Joe Desktop).
I've seen other people talk about those strange apt-get configuration settings. Where are these all documented? There's passing mention of a handful of them in the apt-get man page, but no reference to where the complete list is. Actually, I just figured that was the complete list.
As someone else noted, all of Debian's tools also do the same dumb blind-locking. Extremely annoying. That needs to go out the window: lock when you need it, never at any other time.
Next up, apt-get is bad about handling low disk space. Try apt-get upgrade when you're going from stable to unstable. You need to download 100MB+ of packages for a reasonably complete install. That's more than many people have in/var, which is where apt-get stubbornly insists downloaded files must go. If there's a way to change this, it's undocumented, because believe me I've looked. So apt-get needs to be smarter about downloads. There's not 100MB available? Fine, figure out how much is available and download that much. Install it, delete it, and then download the next chunk. Low disk space situations can actually cause serious problems because dpkg apparently doesn't check free space correctly when it's installing packages. It unpacks it into a temporary directory in/var, runs the configure script, and then tries to copy it to the final location. This is the right way to do it, except that because there's no disk space checking, you can run out of disk space anywhere during that process and get in trouble (like if it happens when replacing libc, for example). So package managers must check to make sure there's enough free space every step of the way, and it must be able to roll back the part of the install that it had already done. I don't expect this to be totally perfect - there will always be race conditions on a multiuser system here - but anything is better than what dpkg has now.
Another important thing is smarter handling of version numbers in the package database. Debian tends to suffer from problems related to this, which is why you see packages named "lib2" and "lib3" (e.g., two completely distinct packages, rather than two packages which happen to have different versions). The reason for the double packaging is that often a program relies on a specific version of the library and it's convenient to have both libraries installed at once. But the package database and versioning system doesn't support two identical packages with different numbers: the software just blindly tries to install the newest one, and bails if it can't do that and still resolve all dependencies. This causes all the sorts of problems RPM users often see, which is two functionally-identical but differently-named packages causing dependency errors, loops, or other problems. It also draws out the single most frustrating aspect of package management for the user, which is that they don't understand why they need a package and therefore don't understand the relevant differences between, say, glibc-2.3.1 and glibc-2.2.4. They usually don't even realize that those are the same package, just two different versions, and so they try to install both... usually with --force flags and disastrous results. Package managers, and packagers (the people), need to get rid of the ambiguity and make sure that users can always say "glibc" and let the package manager worry about the version numbers. This is what Debian was like for a long time, and I'd like to see it be that way again.
"Meaningful defaults" is also a good thing here. I like this about FreeBSD and RedHat. The configuration scripts aren't shy about making decisions for you. That's fine with me, as long as those defaults are sane (usually they are). What I dislike is when the package maintainer starts getting involved in policy (e.g. Debian and OpenSSH), or when the configure script wants its hand held every step of the way (default setting in Debian). Packages should also never have defaults which go against the standard system policy (e.g. Debian's OpenSSH enabling root logins by default, even though FTP, Telnet, and all other similar services do the reverse by default). There also needs to be consistency in the defaults for a package between versions, so users don't get caught off-guard by the change (lots of packages, sadly, are guilty of flip-flopping between defaults when they aren't sure which to use). If all else fails, put a syntax error in the configuration file to force the user to edit it by hand.
This may sound more like criticism than positive things, but I think these emphasize the good parts of package managers. Most of my complaints are about features incompletely or poorly implemented. I basically like working with packages on any modern Unix(-like) system. It's pretty trouble-free and usually Just Works. Most of my complaints are nitpicks or things that bug only power users; in other words, things to improve on in the future, since the great bulk of features have already been implemented and are working great. I think the reason for all the criticism, in my post and others', is that there're so many good aspects of modern package managers that it's shorter to list the defects than the great, useful, working features.
For reasons that escape me, most retailers don't actually show HD programs on their HD floor models. If you go to someplace like a Best Buy and compare the SD sets to the HD sets, you'll be very much unimpressed... because they're running the same DVD-quality demo loop on both sets.
Two reasons, I think. First, they aren't optimistic about being able to sell HDTV equipment because it's expensive and almost nothing uses it (yet). So showing HDTV and regular TV broadcasts on two TVs right next to each other makes the regular TV look like crap. So people see their options as being "spend $2000+ on a TV, or spend $500 on a TV that looks like crap." And second, most people who work in electronics stores get minimum wage, occasionally plus commission, which means they're not paid to think or do things the best way. It's easier to have one signal piped to all the TVs, so that's what they do.
That said, we bought our current TV during the Winter Olympics, which was broadcast in HDTV on some satellite thing (probably DTV, but I don't remember). The difference was striking. It absolutely blew me away. It was like going from VHS to DVD on a great TV, and probably even more impressive than that. For the first time, I was able to see the puck, clear and sharp, in a televised hockey game. (Normally I can see it just fine, but it's blurry and indistinct.) The widescreen HDTVs were especially impressive, although we didn't end up buying one (it was $1000+ more for a feature we can't even use).
I don't see a hugely pressing need for HDTV, which is why I don't think it's taking off at an incredible speed. But I expect that, as people get more used to DVD quality, they will start to want that sort of quality in TV programs as well. Now all we need is for cable companies to get off their butts and do something about this. Satellite has a lot of severe limitations that prevent me, and I suspect a lot of other people, from even considering a switch. If HDTV ends up being sat-only, it'll severely limit its accessibility and make it much less likely ever to catch on.
Well, I have 60GB now, and that's enough. I could use more - every few weeks, I do some housecleaning and move a few gigabytes onto CDs for long-term storage - but I can pretty easily make do with this.
The real difference is that bigger hard drives allow for increased laziness. It's so convenient to have all my media on my computer, even in compressed/low-quality formats. No more sifting through my 500+ CDs to find the one I want: I can find it instantly with a few keystrokes on my computer. One thing I'd really love to have is all my books transcribed into "e-texts." This would be especially great for huge books and trilogies (or worse) that I like to discuss with other people, like The Lord of the Rings and The Wheel of Time. It would be so incredibly useful to be able to search through for a passage that I know I read but just can't find.
So while I'll probably never be able to do what I want with books, unless I steal bad OCR scans of them, at least I can do it with music and movies. Right up until I hit 60GB and have to pull out CDs again. (Having a recording of a TV program on CD is still better than having to wait for it to air again. I would buy DVDs of whole seasons, but so often I like "weird" shows that aren't on DVD and probably never will be.)
I think that's exactly why manufacturers would want these things. Look at the Ford/Firestone fiasco and how much it's cost them, both in the immediate (recalls, lawsuits) and long term (fewer future sales, fewer repeat buyers). If I were an auto manufacturer, this would be a great thing to have, because you could pinpoint a problem and take steps to correct it before it becomes national news. Perhaps I'm just being too optimistic, but that's how I'd use it.
Oh, and one of the things these boxes can do is measure how hard you're stepping on the various pedals and such. Mercedes used this technology on a few thousand cars a while back (as part of a voluntary study) and discovered some interesting things about how people "panic-brake." It turns out that the way most people do it, they actually defeat the antilock braking mechanism. So MB developed a special kind of ABS that works better with how people were doing it.
I imagine you could also use information like this to improve the car's ride, not just its safety, by figuring out how most people drive. This can even include things like most common speeds for gearing the transmission (my car shifts into 4th at 45mph, which makes driving at or near that speed really annoying), how quickly the steering wheel should respond, and all the rest. Yes, manufacturers get some idea of this from their own testing, but a test of a thousand people isn't going to compare to a test of a hundred million in terms of accuracy.
I do have serious concerns about this, though. In particular, I don't want to get a ticket in the mail because I went 60 in a 45 while passing some other car, and I don't want to get a call from my insurance company because some guy backed into me and dented my front bumper a little. But as long as this information is released in a way that doesn't personally identify me, I'd have no problem with it in my car. And if people were allowed to flip a switch and shut it off completely, I wouldn't have a problem with it at all.
seriously, who likes nwn as single player game? maybe somebody who thinks diablo2 is rpg too.
I liked NWN all around. I never got too much into the whole mod scene because most mods are so painfully amateurish. If/when the Linux version comes out, I expect I'll try out more mods to see if there are any that don't suck now.
Anyway, I suspect that I liked NWN for exactly the reasons you didn't. You seem like much more of a hard-core RPGer. Maybe you play them in real life, or have in the past. I'm coming from primarily an adventure game-style background. My first "real" RPG was Ultima VI, which was an RPG in only the extremely general sense, and my first one of the modern era was Baldur's Gate II.
So I guess the go-here-do-this style of NWN didn't bother me much, because you still have more freedom than in any adventure game ever made. I guess I also really empathized with Aribeth's character, which is bad since I'm not a girl, but it really helped draw me into the story. As for the character interaction, I assume you're talking about your henchmen and such, and I really agree with you there.
In some weird way, I think BG2 (for example) was a better game than NWN, but I had a lot more fun playing NWN. With BG2, I would take breaks for weeks because I got bored of doing all the idiotic, pointless quests, or frustrated at not being powerful enough for later battles (because I skimped on all the quests). I was also never into the plot of the game at all. I was much more clinical about playing, which made the game addictive but not fun. Actually, all it did was make me start over and cheat.
I think the reason NWN won, by the way, was that it's much more fun for non-RPGers than a "real" RPG would be. The only crowd that it truly alienates are people like you, who would much rather play full, traditional RPGs. Which group, I suspect, (stereotype alert!) has a disproportionately large representation here on/..
I don't think he understands the real killer, which isn't the length but rather the complexity. This is a bad link (ignore the extraneous space in the middle):
This is bad because people look at it and it's just a string of meaningless gibberish. They don't know what's important or what they can remove; they don't know what it means; and so it looks exactly like any other link from that site. The fact that it's long only makes the problem stand out more: the above would be unreadable if the after-site URL were only 10 characters long instead of 46.
But that's a much better link, because it makes sense to people. The date is the only thing that might serve to confuse people, but I think it would only slow them down for a few seconds at most. The above is really easy for humans to verify as valid or not, because it uses a bunch of rules we already have. Is the date valid? Are all the words in the link spelled correctly? And because each of the components of the URL are split into small, easily-speakable chunks ("opinion," "mysite," and so on), the total length matters less. A 105-character URL made up of 15 words is considerably more readable than a 40-character URL made up of numbers and the occasional comma.
4, Insightful?! How is this not just offtopic, troll-bait FUD? He makes exactly one meaningful claim and provides zero reason for believing it. His other "claim" is supported by a fictional character and is only related tangentially to the topic. (I believe the line of "reasoning" he's using here is "the DoD is talking, the DoD is in charge of wars, Bush runs the DoD, Ashcroft is a Bush employee, therefore the DoD is trying to start a war so Ashcroft can restrict our civil rights." That's about as far off-topic as you can get.)
I guess this works out to a simple "mod parent down" post. So here's something on-topic. I remember reading once an article complaining about how some medical groups are trying to stop people from drinking alcohol at all, for the usual reasons. The article was saying that, if you live your life never doing anything unhealthy, you're going to have a pretty miserable life; and that unhealthy things, in moderation, can have many positive effects (psychologically, for example). My response to that article was: "It's the job of those groups not to consider anything except our health. We, as individuals, need to make the decisions on what's more important to us, and what our definition of 'moderation' is."
My point? It's the same deal here. Of course the DoD is only going to be concerned about how a civilian technology affects military technology. It's their job. It's the job of other agencies, like the FCC and Congress, to decide whether the military's concerns outweigh those of the civilian sector. Don't read too much into this. I think it's perfectly valid that the military has a say in how something like this might work out (especially if it interferes with airport radar and such, which have critical peacetime uses). If you are very concerned as this, you should, as always, write your congresscritter (especially if he's on one of the oversight committees that deals with this sort of thing).
Slashdot Mirror
But seriously, we could spend all day blaming one party or the other for this, or we could discuss the merits and problems of this new decision. Particularly interesting, to me, would be a description of the good things accomplished by the existing regulations. I was under the impression that the whole partial-deregulation quagmire was universally perceived as a disaster. Apparently you don't think it was. Why?
What we should get out of this whole thing is real innovation and competition. Now that it's becoming increasingly difficult to be a successful DSL provider, maybe we'll start to see viable alternatives to cable and DSL. Wireless has real potential, if you can make it sufficiently low-cost and secure ("secure" in the sense of making it difficult for people to hijack).
Oh, and by the way, wherever there's a cable company there's competition. We get our phone service from our cable company here. The only monopoly is in the phone lines, so all you need to do is what the cable companies are doing (and doing very successfully): find an alternative to the phone lines.
Don't believe me? Read the JFS overview from IBM, which says:
The only benefit JFS has over UFS+SU in this context is faster on-crash fsck times. And it only takes about a minute to check a 60GB UFS filesystem after a crash, which is about 3 orders of magnitude better than e2fsck (I don't know how speedy jfs.fsck is in non-replay mode).The chief benefit of JFS for FreeBSD is going to be portability. Which is a pretty big one, although I don't see JFS supplanting UFS before FreeBSD 6.0, if then.
First, often security holes are not immediately disclosed. The discoverer will instead contact the company responsible for fixing the holes and give them a certain amount of time to acknowledge, examine, and then fix the hole. Only if the company involved ignores the problem or doesn't fix it in a timely manner is the hole publicly revealed without a fix in-hand.
Second, there's an obvious difference here. If Apache has a security hole, eventually the Apache folks will release a patch that fixes it. Where's my patch from God that makes me immune to anthrax?
If you insist on looking at human security as similar to computer security, try this. Security by obscurity is only one part of the process, and probably the least important. We also buy off former Soviet scientists to keep them from defecting, keep careful tabs on the equipment needed to build all sorts of nasty stuff, use our intelligence to track groups which might have the capability of making WMDs, and all the rest. Obscurity is one small part of the Onion of Security.
I don't know if it happened that way, but it's certainly the first thing I'd try in his place.
Anyway, I'm excited by this because, well, competition is almost always a good thing. Hopefully gcc and Watcom can feed off each other and both products will improve. And perhaps more importantly for the build-everything users, another open source compiler might start moving people (like the developers of autoconf) to better support non-gcc compilers. This way, users who prefer Watcom's (or Intel's, or...) compiler can use it without as much tweaking.
The "64GB" options in the kernel just enable the page address extension (PAE), which is a way of addressing up to 64GB for the entire OS. So you can have 16 processes using 4GB each, and you'll be using all 64GB, but you can't have 8 processes using 8GB each.
It's not impossible to write an OS which lets each process access up to 64GB RAM, but it would be nontrivial. It would require many different segments and probably a lot of page faults. And it would be a lot of work, unless I'm missing something very obvious.
4GB is still a lot by any standard, but the problem is that the kernel, for example, needs to have some of its structures appear in the process's address space. Shared libraries also need to be in each process's address space, even if it's in memory only once. Even better, you need to leave room for the heap to grow as well as for user-loaded entities (like dlopen()'ed shared objects). In practice, I understand the default restriction for Linux is somewhere in the neighborhood of 1.5GB per process, though you can increase that to 3GB with some libc tweaks. There are a few kernel patches to raise that limit further to 3.5GB, but that's the absolute ceiling (and you are sacrificing what may be important things, like SysV shared memory segments).
Even now, it's not uncommon to see gaming machines with 1GB RAM or more. Even small servers will often have 4GB RAM. In a few years, the number of "high-memory" systems is only going to increase as advances in technology continue to drive down the cost of RAM and drive up the requirements of software. This is especially the case as databases become more important and commonplace in the business world. Everyone uses them now, but we can expect to see them used more often, and in more diverse places, than in the past.
There is also a hope among many of us that Intel and AMD will use this opportunity to create good chips, not just cheap ones. They have the opportunity to fix a lot of the stupid design decisions Intel made 20 years ago and put together a modern, clean system. Unfortunately, it doesn't look like this is going to happen (I don't think anyone at AMD has had an original idea in their entire lives, and Itanium is being designed by committee), but this is the hope. In short, we may not see any immediate performance gains, but in the long term, the design of the chips would enable faster improvements than we're getting with IA32s right now.
It would also be lovely to see the tool which manages all this unify all the ACL-like aspects of the system into a single interface. Firewalls, filesystem ACLs, and privilege delegation are all remarkably similar, it'd be great to be able to define them selectively in groups (I think SELinux calls them "contexts") and confer them to various processes. Daemons can bind to ports, but not regular users? Easy: set the firewall ACL policy to deny, then grant the "daemon" context an exemption. Then tie in other useful privileges, like the ability to write to /var/run and send messages to syslogd. All these things are obviously related conceptually, but currently you'd need 3 tools to do it all (I don't think it's possible to regulate syslogd access this way, period, but I'm being optimistic and assuming it is).
Unfortunately, from what I saw of SELinux when I last used it, all this is some time off... especially the part where it's easy to administer and use. But to end on a positive note, there are a bunch of people who recognize this problem and are working hard to correct it.
The only possible explanation I can think of is that there's a lost of history-rewriting going on so we can get around the simple fact that people do a lot of stupid shit, knowing full well that it's stupid (and not caring). "Why did you smoke if you knew it was bad?" "Oh, I didn't know - the evil tobacco companies lied to me!" "Why did you sit in front of your computer for 16 hours a day?" "Nobody ever told me it was unhealthy!" Much better than the truth, which is often "I knew it was bad for me, I just didn't care."
It's pretty much analagous to all the various anti-theft things you can put on your car, ranging from a keyed ignition to a fuel pump cutoff. Anyone who really wants to steal your car is going to do it. The only purpose to all this anti-theft garbage is to make your car less convenient to steal than the cars next to it in the parking lot.
The time to start worrying about this sort of thing is when those computers cost $5000 and everybody can buy one and use it for evil.
If I were Intel's CEO, you'd better believe I'd go to bed hoping my researchers found some magic lamp that night. And if I were an Intel shareholder - which I am - I'd damn well want my company to take advantage of any competitive edge it found, especially improved technology.
I'm not saying your point is without merit, but remember that the best security policies are built like onions, with many layers of redundant protection. Some of the features that are being talked about for the "Trusted Computing" initiative could be a useful and important part of a complete security policy (though I doubt their utility for Joe Desktop).
(I have too much karma!)
And Itanium has much greater vendor support. Not saying much, since Alpha has only slightly more vendor support than OS/2.
Then you're doomed to use truss or strace or whatever, because a normal debugger won't help you there anyway.
I've seen other people talk about those strange apt-get configuration settings. Where are these all documented? There's passing mention of a handful of them in the apt-get man page, but no reference to where the complete list is. Actually, I just figured that was the complete list.
Next up, apt-get is bad about handling low disk space. Try apt-get upgrade when you're going from stable to unstable. You need to download 100MB+ of packages for a reasonably complete install. That's more than many people have in /var, which is where apt-get stubbornly insists downloaded files must go. If there's a way to change this, it's undocumented, because believe me I've looked. So apt-get needs to be smarter about downloads. There's not 100MB available? Fine, figure out how much is available and download that much. Install it, delete it, and then download the next chunk. Low disk space situations can actually cause serious problems because dpkg apparently doesn't check free space correctly when it's installing packages. It unpacks it into a temporary directory in /var, runs the configure script, and then tries to copy it to the final location. This is the right way to do it, except that because there's no disk space checking, you can run out of disk space anywhere during that process and get in trouble (like if it happens when replacing libc, for example). So package managers must check to make sure there's enough free space every step of the way, and it must be able to roll back the part of the install that it had already done. I don't expect this to be totally perfect - there will always be race conditions on a multiuser system here - but anything is better than what dpkg has now.
Another important thing is smarter handling of version numbers in the package database. Debian tends to suffer from problems related to this, which is why you see packages named "lib2" and "lib3" (e.g., two completely distinct packages, rather than two packages which happen to have different versions). The reason for the double packaging is that often a program relies on a specific version of the library and it's convenient to have both libraries installed at once. But the package database and versioning system doesn't support two identical packages with different numbers: the software just blindly tries to install the newest one, and bails if it can't do that and still resolve all dependencies. This causes all the sorts of problems RPM users often see, which is two functionally-identical but differently-named packages causing dependency errors, loops, or other problems. It also draws out the single most frustrating aspect of package management for the user, which is that they don't understand why they need a package and therefore don't understand the relevant differences between, say, glibc-2.3.1 and glibc-2.2.4. They usually don't even realize that those are the same package, just two different versions, and so they try to install both... usually with --force flags and disastrous results. Package managers, and packagers (the people), need to get rid of the ambiguity and make sure that users can always say "glibc" and let the package manager worry about the version numbers. This is what Debian was like for a long time, and I'd like to see it be that way again.
"Meaningful defaults" is also a good thing here. I like this about FreeBSD and RedHat. The configuration scripts aren't shy about making decisions for you. That's fine with me, as long as those defaults are sane (usually they are). What I dislike is when the package maintainer starts getting involved in policy (e.g. Debian and OpenSSH), or when the configure script wants its hand held every step of the way (default setting in Debian). Packages should also never have defaults which go against the standard system policy (e.g. Debian's OpenSSH enabling root logins by default, even though FTP, Telnet, and all other similar services do the reverse by default). There also needs to be consistency in the defaults for a package between versions, so users don't get caught off-guard by the change (lots of packages, sadly, are guilty of flip-flopping between defaults when they aren't sure which to use). If all else fails, put a syntax error in the configuration file to force the user to edit it by hand.
This may sound more like criticism than positive things, but I think these emphasize the good parts of package managers. Most of my complaints are about features incompletely or poorly implemented. I basically like working with packages on any modern Unix(-like) system. It's pretty trouble-free and usually Just Works. Most of my complaints are nitpicks or things that bug only power users; in other words, things to improve on in the future, since the great bulk of features have already been implemented and are working great. I think the reason for all the criticism, in my post and others', is that there're so many good aspects of modern package managers that it's shorter to list the defects than the great, useful, working features.
That said, we bought our current TV during the Winter Olympics, which was broadcast in HDTV on some satellite thing (probably DTV, but I don't remember). The difference was striking. It absolutely blew me away. It was like going from VHS to DVD on a great TV, and probably even more impressive than that. For the first time, I was able to see the puck, clear and sharp, in a televised hockey game. (Normally I can see it just fine, but it's blurry and indistinct.) The widescreen HDTVs were especially impressive, although we didn't end up buying one (it was $1000+ more for a feature we can't even use).
I don't see a hugely pressing need for HDTV, which is why I don't think it's taking off at an incredible speed. But I expect that, as people get more used to DVD quality, they will start to want that sort of quality in TV programs as well. Now all we need is for cable companies to get off their butts and do something about this. Satellite has a lot of severe limitations that prevent me, and I suspect a lot of other people, from even considering a switch. If HDTV ends up being sat-only, it'll severely limit its accessibility and make it much less likely ever to catch on.
The real difference is that bigger hard drives allow for increased laziness. It's so convenient to have all my media on my computer, even in compressed/low-quality formats. No more sifting through my 500+ CDs to find the one I want: I can find it instantly with a few keystrokes on my computer. One thing I'd really love to have is all my books transcribed into "e-texts." This would be especially great for huge books and trilogies (or worse) that I like to discuss with other people, like The Lord of the Rings and The Wheel of Time. It would be so incredibly useful to be able to search through for a passage that I know I read but just can't find.
So while I'll probably never be able to do what I want with books, unless I steal bad OCR scans of them, at least I can do it with music and movies. Right up until I hit 60GB and have to pull out CDs again. (Having a recording of a TV program on CD is still better than having to wait for it to air again. I would buy DVDs of whole seasons, but so often I like "weird" shows that aren't on DVD and probably never will be.)
Oh, and one of the things these boxes can do is measure how hard you're stepping on the various pedals and such. Mercedes used this technology on a few thousand cars a while back (as part of a voluntary study) and discovered some interesting things about how people "panic-brake." It turns out that the way most people do it, they actually defeat the antilock braking mechanism. So MB developed a special kind of ABS that works better with how people were doing it.
I imagine you could also use information like this to improve the car's ride, not just its safety, by figuring out how most people drive. This can even include things like most common speeds for gearing the transmission (my car shifts into 4th at 45mph, which makes driving at or near that speed really annoying), how quickly the steering wheel should respond, and all the rest. Yes, manufacturers get some idea of this from their own testing, but a test of a thousand people isn't going to compare to a test of a hundred million in terms of accuracy.
I do have serious concerns about this, though. In particular, I don't want to get a ticket in the mail because I went 60 in a 45 while passing some other car, and I don't want to get a call from my insurance company because some guy backed into me and dented my front bumper a little. But as long as this information is released in a way that doesn't personally identify me, I'd have no problem with it in my car. And if people were allowed to flip a switch and shut it off completely, I wouldn't have a problem with it at all.
Anyway, I suspect that I liked NWN for exactly the reasons you didn't. You seem like much more of a hard-core RPGer. Maybe you play them in real life, or have in the past. I'm coming from primarily an adventure game-style background. My first "real" RPG was Ultima VI, which was an RPG in only the extremely general sense, and my first one of the modern era was Baldur's Gate II.
So I guess the go-here-do-this style of NWN didn't bother me much, because you still have more freedom than in any adventure game ever made. I guess I also really empathized with Aribeth's character, which is bad since I'm not a girl, but it really helped draw me into the story. As for the character interaction, I assume you're talking about your henchmen and such, and I really agree with you there.
In some weird way, I think BG2 (for example) was a better game than NWN, but I had a lot more fun playing NWN. With BG2, I would take breaks for weeks because I got bored of doing all the idiotic, pointless quests, or frustrated at not being powerful enough for later battles (because I skimped on all the quests). I was also never into the plot of the game at all. I was much more clinical about playing, which made the game addictive but not fun. Actually, all it did was make me start over and cheat.
I think the reason NWN won, by the way, was that it's much more fun for non-RPGers than a "real" RPG would be. The only crowd that it truly alienates are people like you, who would much rather play full, traditional RPGs. Which group, I suspect, (stereotype alert!) has a disproportionately large representation here on /..
I guess this works out to a simple "mod parent down" post. So here's something on-topic. I remember reading once an article complaining about how some medical groups are trying to stop people from drinking alcohol at all, for the usual reasons. The article was saying that, if you live your life never doing anything unhealthy, you're going to have a pretty miserable life; and that unhealthy things, in moderation, can have many positive effects (psychologically, for example). My response to that article was: "It's the job of those groups not to consider anything except our health. We, as individuals, need to make the decisions on what's more important to us, and what our definition of 'moderation' is."
My point? It's the same deal here. Of course the DoD is only going to be concerned about how a civilian technology affects military technology. It's their job. It's the job of other agencies, like the FCC and Congress, to decide whether the military's concerns outweigh those of the civilian sector. Don't read too much into this. I think it's perfectly valid that the military has a say in how something like this might work out (especially if it interferes with airport radar and such, which have critical peacetime uses). If you are very concerned as this, you should, as always, write your congresscritter (especially if he's on one of the oversight committees that deals with this sort of thing).