"Telling application developers to use a database is bullshit."
I'm not telling application developers to use a database; I'm explaining what's driving a remark others have made. Application developers can use whatever suits their need. If a database is what they want, then sure, use one. If something else is better, use that.
"A open-write-close-rename sequence merely asks for atomicity without durability, something that's perfectly reasonable."
You may think it's perfectly reasonable, but you're asking for atomicity across multiple operations. So really want you want is transactions. To the best of my knowledge, neither Linux, nor Windows, nor Mac OS X, nor any of the BSDs, offer transactions in the filesystem layer. I've always thought such would be a good idea, but I don't think it exists.
Further, even if filesystem transactions did exist, the application would have to request it. There's no way for the OS to magically divine what an application considers a filesystem transaction to be; the application has to tell it. So the order of operations would need to be begin-open-write-close-rename-commit.
"all the application wants is for either the old version of a file or the entire new version to appear on a reboot"
Then the application should call fsync on the new file before removing the old one. That's the only mechanism the POSIX specification provides to guarantee something has been committed to disk. It may be more than the application really wants or needs, but it's all POSIX provides.
One can argue POSIX should do more, of course. More on that below.
"He doesn't care at the instant of the rename whether that replacement has been recorded on disk..."
Actually, yes he does, because the operation he's requesting is to destroy the only known-good file. It's not the OS's fault that the programmer didn't actually make sure his new copy was good before he destroyed the old one.
The programmer may have intended for the OS to make sure the new copy was good, but he never asked it to do so (i.e., with fsync).
"asking for that same durability in a multi-file configuration setup is just stupidly degrading performance."
So, baring new system calls for filesystem transactions, what should the filesystem do, then? Serialize all I/O operations? Now you're destroying the I/O scheduler and killing multitasking performance.
Maybe there's another option here that I'm not seeing.
"open-write-close-rename is saying something fundamentally different from open-write-fsync-close-rename"
Yes, one is safe, the other is unsafe.
I think the problem here is you're implying semantics which don't actually exist in the OS or it's interface specification. Programming by "gee I really wish things worked this way" is a bad way to do things.
Now, maybe you want to make the argument that the OS should provide transactions. I'd even agree with you. But one doesn't write code based on a feature request; you write code based on what the system actually does.
"Nope, it writes a new file and then renames it over the old file, as rename() says it is an atomic operation - you either have the old file or the new file. What happens with ext4 is that you get the new file except for its data. "
Two things are happening: (1) KDE is writing a new inode. (2) KDE is renaming the directory entry for the inode, replacing an existing inode in the process.
KDE never calls fsync(2), so the data from step one is not committed to be on disk. Thus, KDE is atomically replacing the old file with an uncommitted file. If the system crashes before it gets around to writing the data, too bad.
EXT4 isn't "broken" for doing this, as endless people have pointed out. The spec says if you don't call fsync(2) you're taking your chances. In this case, you gambled and lost.
KDE isn't "broken" for doing this unless KDE promised never to leave the disk in an inconsistent state during a crash. That's a hard promise to keep, so I doubt KDE ever made it.
A system crash means loss of data not committed to disk. A system crash frequently means loss of lots of other things, too. Unsaved application data in memory which never even made it to write(2). Process state. Service availability. Jobs. Money. System crashes are bad; this should not be news.
The database suggestion some are making comes from the fact that if you want on-disk consistency *and* good performance, you have to do a lot of implementation work, and do things like batching your updates into calls to write(2) and fsync(2). Otherwise, performance will stink. This is a big part of what databases do.
As someone else suggested, it's perfectly easy to make writes atomic in most filesystems. Mount with the "sync" option. Write performance will absolutely suck, but you get a never-loses-uncommitted-data filesystem.
I'd dispute your claim that hierarchy is at a disadvantage for defense. Loose groups are good for offense because you can't just counter-attack the command and control structures. But for building a foundation for attack, you want something strong and solid.
I say "your claim" because while I haven't read that RAND report in completeness, a cursory examination suggests that they don't particularly favor an unstructured defense.
"Wait, NIST? You mean the guys who sit around and define the meter and mile and kilogram?;)"
The National Institute of Standards and Technology, yes. Check out the NIST Computer Security Resource Center: http://csrc.nist.gov/ It's actually good stuff, but again, redundant with the eleventeen other US Federal agencies publishing guidance. Confusion over authority helps nothing, least of all security.
Oh, and BTW: It's actually the BIPM that defines the SI units like meter and kilogram. (BIPM = Le Bureau international des poids et mesures, the International Bureau of Weights and Measures, headquartered in France.)
"Disobeying a corrupt director won't get you hanged."
In fairness, disobeying a corrupt order will generally not lead to hanging. It likely will lead to a Court Martial, but if the order truly was corrupt, you'll be let off. Not that "I don't agree" does not make an order corrupt.
Still, I think you do make a fair point, so touche. Generals do command large forces with large weapons. The DCI commands a rather smaller force, most of whom don't have weapons, and most of those who do have much smaller weapons.
Of course, the CIA used to operate its own air force (the U-2 and SR-71 were originally CIA programs). Whether they still do, of course, is a matter of public speculation.:) But even then, the U-2 and SR-71 were never fitted with weapons systems. Well, not that the public knows about, anyway. Publicly, the SR-71 was intended to have the option of weapons capability; the option was simply never exercised. The neat thing about black ops is that there's always the possibility that they did something and just never told us.
"How common is it for a coup d'état to come from a minister of interior security?"
Well, since the "minister of interior security" in many authoritarian governments actually wields quite a lot of power, it's actually not uncommon. Look at the 1991 coup attempt in the USSR: That came from the KGB (Committee for State Security). The NKVD (KBG's predecessor under Stalin) likewise was the organization for administered the deaths or "disappearance" of millions of people.
But let's just look at the US (which, despite all its fault, is far from authoritarian). None of the organizations I named, aside from maybe the FBI, is concerned solely with interior security. Some of them are chartered explicitly to not be concerned with interior security.
But that itself is another fallacy: A great many security threats (I'm tempted to say the majority of them) know no border. So it's not practical to draw a line and say "this agency will only concern itself with interior threats". Sure, it would be nice to say the FBI should only concern itself with domestic cases, but the problem is that you generally don't know the full extent of the case until the case is solved.
"Except Vista and Windows 7 *don't* make Admin accounts by default."
I don't know about Win 7, but Vista prompts the user to create a new account during install. That account is assigned admin privileges. It's not even required to have a password.
As I believe is required at this point: *BZZT*, wrong, but thanks for playing!
"What bothers me is nobody seems to answer the question: "What *should* they be doing?" in a reasonable manner."
Require users to create a separate admin account from the limited user account. Require decent credentials on the admin account (e.g., non-trivial password, or biometric, or whatever). If the user also wants credentials on their limited account, require those credentials to be different vs the admin account. Require regular, day-to-day operations to be performed under the limited account. Elevate operations which can effect system stability or security to the administrator account from the limited account, without requiring a log off, user switch, command prompt, special right-click menu option, or anything else cumbersome. Require the user to present credentials before elevating.
In other words, implement security best practices that have existed in the computer industry since the 1960s.
The real killer is that UAC can be configured to do this. You can have two accounts, and have it prompt for an admin password when needed. It's just not the default configuration.
Microsoft claims they didn't go this route because they thought people were too used to running as admin all the time and wouldn't give it up. But that seems like bullshit, because Microsoft forced plenty of other unwanted changes down people's throats with Vista. Why is security somehow different?
Per-process capabilities and sandboxing are also a good idea, for things like MSIE. From what I've seen, though, either the design or the implementation is poor, because they haven't been as effective as they should at stopping things like trojans (adware/spyware disguised as legit software to get the user to install it).
The object of cybersecurity is to prevent people from interfering with out computers. The NSA's JOB is to interfere with our computers.
Actually, the NSA is charged with the security of the nation's communications, including the private sector. "National Signals Agency" would be a better expansion ("signals" including communications and computers in the GOVSEC world). Sure, they spy on everybody. How much spying they should do is a quagmire of a political debate I'm not about to involve myself in here. But they also work to make sure the nation's signals infrastructure is secure.
As I pointed out in another post, the NSA publishes a lot of security guidance. It's very well written, very real-world oriented, and public. The private sector would do well to take lessons from it.
They've largely given up on controlling crypto. Of course, that just leads one to wonder -- is that because they've recognized it as a lost cause, or because they don't need to control it to crack it anymore?
Um, yah. Do you have any real idea what you're talking about?
The NSA is full of very smart people. They employ more mathematicians and computer scientists than any other organization in the world. Their IA division is very good. They publish lot of very good, public computer security guidance. The computer world would be a more secure place if most organizations tried to adopt some of their recommendations.
"There should be a focus and funding on implementing BGPSEC and DNSSEC since this is where many of the major vulnerabilities lie,"
Huh?
DNS and BGP are generally run by people who know what they are doing. While there are protocol vulnerabilities, they've historically been pretty resistant to attack. Compromises have been local and stayed local, like they should.
Compare that to the massive data breaches that major financial, health care, and government organizations have reported. Compare that to the hundreds of thousands -- if not millions -- of compromised home computers service as spam cannons and botnet members.
DNS and BGP are not nearly as big a concern as that.
"One of the key reasons that there are so many agencies is that there is a clear dividing line in US law between the military and civilian agencies. "
It has a lot more to do with historical accident than separation of powers. The agencies each formed from different power bases, with slightly different but overlapping missions, and have grown into institutions.
DHS is a *great* recent example. DoD, NSA, CIA, FBI, NRO, NCSC... what, we didn't have *enough* agencies that were already supposed to be protecting us for threats? But there was a crisis, so the existing power base creates a new organization to solve all the problems, rather than trying to fix the existing organizations.
And frankly, the whole "military" vs "civilian" thing is fairly specious. If we're worried about abuse of government power, the fact that the NSA is a nominally "civilian" agency doesn't really matter. They can still abuse their power just as well. What difference does it make that their CO is a "Director" rather than a "General"?
I should state that I'm not an anti-government nut. I just think there's too much overlap in all this. The NSA, CIA, NRO, and Army/Navy/AF intelligence should all be one damn organization. When it comes to computer security, there should be one agency with authority and one set of rules and documentation. As it is now, we've got NSA, NCSC, DISA, DSS, CIA DCI, NIST, and each service's SAPCO each with their own way of doing things! It's insane! Should I be writing my security plan to NISPOM standards, or JAFAN, DCI 6/3, or NSA SNAC, or DISA STIG, or...? And $DEITY help you if you want to use one information system for multiple government programs under different authorities!
Hell, there shouldn't be separate field command structures for Army vs Navy vs AF vs USMC. Do away with this Joint Command bullshit and put one damn power structure in place. But holy Internet gods, you suggest merging the service branch departments, and you get treated like you just suggested burning the Constitution and making the leader of the US Communist party dictator for life in place of the President.
[citation needed] Or maybe this is "weasel words". In any case, "Says who?"
Everybody *but* DJB. And since DJB has apparently pissed off just about the entire rest of the population of the planet at this point, his pet-project ideas have just about zero chance of being adopted widespread. So, in a very real sense, DNSCurve is by definition the least-good way to secure DNS, because it will never see real adoption.
Whether or not DNSCurve has any good ideas or not doesn't matter, because DJB has burned every bridge to his own little island. And it turns out that a network that doesn't connect to anything isn't very interesting.
Samba runs as root for a few different reasons that I know of: 1. bind to privileged ports (1024) 2. set{e,r}{u,g}id for the user being authenticated 3. RPC-based system administration
If it was just the first, I bet it could prolly drop root soon after startup. If it was just the first and the second, it might be able to drop root after authenticating, since each connection gets its own process. Samba may already do some of this, for all I know. Alternatively, implementing this may be difficult for architectural reasons, which may or may be solvable via code restructuring.
But for the third, it has to run as root all the time. What this refers to is the ability to perform system administration tasks (like adding/changing/deleting users, groups, computers, etc.) via Microsoft's RPC mechanism. This is how Windows does this, and Samba supports quite a bit of it. Notably, if you're doing to support Windows domains on Samba, it needs to be able to create host OS (Unix) accounts for users and machines.
It's probably theoretically possible to develop some kind of frontend/backend layer for process privilage separation, but at that point, you're basically just implementing all the protocol work Samba has to do all over again, in an internal protocol. If you couldn't get it right the first time, I wouldn't expect this try to be much better.
Remember, Samba aims to be bug-for-bug compatible with Microsoft Windows, which means inheriting any brain damage present in SMB/CIFS. If you want a clean design, this is the wrong place to look.
"Address way more memory in total, and way more per app"
As I've said to others: I never claimed Long Mode was useless, just overrated. If one is actually working with datasets that large, it's a huge win. And certainly Long Mode has some design improvements over Protected Mode. But architectural improvements don't trump practical concerns in my book. If my first priority was a clean architecture, I'd use a DEC Alpha. Compatibility and installed base are why we're all using 8086 descendants in the first place.
"Finally, the open source community only took a year or two to transition to perfect 64-bit support, and it's been fine since at least 2005."
A year or two? I spent significant time debugging 32-bit assumption problems with Linux on the Alpha in 1996. Not 2006 -- 1996. The problems have been out there for a *long* time.
Fine since 2005? I was just last week involved in trying to solve a 32/64-bit compatibility issue with IEEE-1394 support. Granted, the guy was using a CentOS 5 system, and CentOS doesn't adopt the latest changes as they happen. But that's because other people/software (even F/OSS) don't always adopt the latest changes either. It makes sense to wait for things to stabilize before adapting.
So I don't see the picture as so rosy. A lot of F/OSS code is okay (especially really popular things like Firefox), and things are improving all the time. But it's far from a given.
"Adobe, Microsoft... see, this is why we can't have nice things!"
"I cant believe you are a computer user/enthusiast."
I'm an IT management type, which means I care a lot more about actual costs and actual benefits. I'm sure that makes me non-an-enthusiast, since I'm not enthusiastic about change for the sake of "my number is bigger than your number". Sorry if that impinges your sense of self-worth.
"Lets just limit CPU speed too then."
Apples and oranges. Increasing MIPS doesn't cost anything. Well, it costs R&D, but that's factored into the processor's price. And if you're an early adopter, you'll pay dearly for the latest silicon, but those of us buying on the price/performance curve do well.
"3D modelling and animation for a living. I definitely need 64-bit"
Like I said, it has its applications. I was lumping 3D into "engineering workstation", although I realize now that probably wasn't clear to those working chiefly in the consumer space. In the business world, high-end production like that is done on a class of computers generally called "engineering workstations", though they're not that different from what you buy off the shelf at Circuit City. Better graphics cards and better tech support, mainly.
I also left out games, which several replies have said are actually using datasets large enough to care about a 2 or 4 GiB address space limit. I'm not a gamer, so I'll take their word for it. So games might be the first practical application of Long Mode in the mass-market consumer sector.
"The same goes for Music. There are lots of folks editing their own music in their basements. How about video?"
Considering that music and video NLE was being done on 32-bit platforms with "Its quite easy to make a photoshop file that eats up 2GB of ram."
Doing the math, a 24-bit color bitmap with an 8-bit alpha channel at 2 GiB works out to roughly 32,000 x 32,000 pixels. That's a big image. I'm no photographer; what's considered "high rez" these days?
"Frankly I'm for now because i'm about progress..."
Longer, lower, wider, faster, bigger, newer... must be progress, right?
I think the big press for 64-bit is more about propping up bloated software whose development is totally out-of-control and leaks memory like a sieve. Rather than improving software development -- which would would also yield better reliability, security, performance, and compatibility -- we just keep throwing more hardware at it. That's progress for you.
"Its also about running multiple applications at the same time that demand lots of ram."
As discussed, proper support for PAE would solve the problem of a multi-process workload whose individual needs fit within Win32 but whose total memory load exceeds 4 GiB.
I normally don't reply to anons, since they usually aren't watching for replies, but you seem to know what you're talking about, and do raise some good points, so I'll make an exception. (Good for you!)
"Or they just realize the benefits of using a sane instruction set architecture."
x86_64 is not "sane", it's just less broken than i386. Take a look at the DEC Alpha architecture sometime if you really want a clean 64-bit platform. It's such a pity Intel had Compaq kill it off to keep it from competing with IA-64.
"The switch from i386 -> x86_64 is not about memory addressing. It's about alleviating the register starvation that plagues the Intel instruction set."
x86_64 is very much about virtual address word size, it's just not the only thing about it. Perhaps I do underestimate the benefit of increasing from 8 to 16 general-purpose registers. Maybe it's because most architectures have 30+ GP registers available, so it still seems like a day late and a dollar short. And as I mentioned, gains can be offset by costs. But hey, if the extra registers yield a significant performance improvement for your applications, more power to you. I'm just saying it's overrated, not useless.
"I'm not sure about this, but I read somewhere that on Windows XP and Vista, enabling DEP will disable the support for PAE."
DEP is implemented by setting the NX bit (No Execute) on memory pages containing only data. The NX bit is only available in the larger page tables you get with PAE. So DEP requires PAE.
However, workstation flavors of Win32 force all hardware address to below the 4 GiB mark, in order to maintain compatibility with drivers which assume a 32 bit physical address word. The "Advanced Server" flavors fully support PAE, allowing more than 4 GiB of RAM to be used on Win32.
But Win i386 still limits physical addresses to under 4 GiB to keep crappy drivers from crashing the system.
"It's not Windows that does this, but the BIOS assigns these addresses. Windows simply does not relocate them, and I don't know if such relocation is possible."
Such a relocation is indeed possible, if your hardware supports it. Actually, what is typically done is that non-RAM hardware stays below 4 GiB, and any displaced RAM is moved to locations above 4 GiB. Google "memory hoisting".
All this 64-bit support is tricky, because for it to work: * CPU has to support it (but most do, these days) * Core logic chipset has to support it (ditto) * Motherboard OEM had to actually run traces for it (varies) * BIOS has to not screw things up * PCI stuff has to support DAC (Dual Address Cycle) * Device drivers have to be able to cope with 64-bit addresses * OS kernel has to support all of the above
There's lots of places for things to go wrong.
"Why should you worry about running 15+ year old [Win16] code on a new OS?"
Welcome to the world of business IT, where 30-year-old code is still in production use all over the place.:)
Long Mode also means potential compatibility issues with crappy 32-bit code.
"Can you give an example? 32-bit code doesn't even know it's running on a 64-bit OS unless it explicitly asks."
Lots of source code assumes integers and pointers are all 32 bits wide. Recompiling for a 64-bit platform uncovers all sorts of bad assumptions. Was a huge problem in the *nix world when 64-bit platforms arrived on the scene. Now it's a huge problem for the 'doze world.
Only applies to source recompiles, of course, but if you're going to target i386 for all your applications, why bother with a 64-bit platform? A chicken-and-egg problem, to be sure.
[insert vague insult on your knowledge or ancestry here]
"There is a performance penalty and it is a hackish way of solving the problem."
A good portion of the performance penalty is already taken due to DEP, which needs the NX bit, which is only available in the larger page tables PAE provides. So PAE is enabled, but workstation flavors of Win32 won't use memory above 4 GiB due to driver compatibility concerns.
"With certain desktop appplications, notably more advanced games, I could see the per-process limit being hit... "
Games are not something I was considering. I'm a professional IT management weenie, so I don't get much exposure to the latest-and-greatest. (My home Wintendo PC tends to trail the curve; it's cheaper, and I don't have the time for gaming I once did). So my analysis is indeed lacking there. I'll bow to your experience in this area.
"There is a reason why distributions provided PAE-disabled kernels in x86 world."
Because certain workloads do indeed benefit from memories larger than 4 GiB, as I stated. It's not that a 64-bit architecture is useless -- hell, I was supporting 64-bit Alpha boxes running Linux back in 1996 -- it's just it's overrated. Most people use it as ammo in penis-length competitions, nothing more.
"Though you mention buggy 32-bit code having problems in long mode, I have never seen that occur in Linux or Windows."
It may not be common, depending on what you're doing. I address this briefly in my cousin post here:
"I haven't run into 16-bit applications in an eternity though."
Not everyone does. It's depressingly common in the business world, though. Portions of Intuit QuickBooks were still using Win16 code three years ago, which was the last I touched that piece of crap. We've got an ERP system at work that's full of Win16 modules, too.
I expect, with the big push on for Win64 (for whatever reason, be it real performance or chest-thumping), code modernization is (or will be) becoming more of a priority for publishers. Which is certainly all to the good.
FYI, PAE doesn't get you anything much on workstation flavors of Windows, and the/3GB switch has a number of issues, too. For more information, see my cousin post here:
"However, I've not run into any troubles using linux x86_64 with common software over the past three years. "
You're correct for most modern, Open Source applications. And plenty of others, too.
However, if you're dealing with older software that hasn't seen widespread adoption, a lot of it assumes integers and pointers are 32 bits wide. Such software is more common in niche environments, such as scientific, university, lab, and company-internal systems.
And if it's binary-only stuff, it's a whole 'nother ball game. Adobe Flash is the canonical example. They're still "alpha test" for Linux x86-64, and it was a browser-crash-in-a-box last I tried it. (Not that the i386 flavor of Flash is much better.)
If you're lucky enough to be able to run 64-bit clean everywhere, more power to you.:)
"There IS an OS boot string to let processes address up to 4Gb of RAM (or more)..."
No. Not for Win32.
There is the/3GB switch. This enables what Microsoft calls 4GT (4 gigabyte tuning). It changes the kernel/user split from 2/2 to 1/3. However, applications have to be compiled with a particular option (IMAGE_FILE_LARGE_ADDRESS_AWARE) to use it. Further, it robs the kernel of memory it might need for other things, so it's not a no-brainer. It's mainly useful if you're going to be running a single large application on the computer (e.g., Exchange Server). If you're running a multi-process workload, you're often better off giving the kernel its memory. And you're still limited to a 4 GiB virtual address space.
There is the/PAE switch. PAE = Physical Address Extension, which changes the physical address word size from 32 bits to 36 bits. This will let the processor address up to 64 GiB of RAM. However, you're still limited to a 4 GiB virtual address space. It's useful for a large multi-process workload. For example, a machine with 8 GiB of RAM can run several large tasks, each task using up to 2 or 3 GiB of memory.
Further, on the "workstation" versions of Windows (2000 Pro, XP, Vista), the/PAE switch doesn't actually increase the amount of physical hardware address space the operating system will use. It does enable PAE, but Windows still ignores physical addresses above 4 GiB. Also, PAE will already be enabled on XP SP2 and Vista, to get the NX bit.
There is also AWE (Address Windowing Extensions). This is not an OS boot switch; it is a collection of system calls. AWE is just bank switching all over again (like the ancient MS-DOS EMS). To obtain more than 2 (or 3) GiB of primary storage (memory), an application can switch pages of memory in and out of its address space. However, it cannot access pages not actively mapped to its address space, so the application basically has to do its own memory management. Ick.
*None* of this applies to Win64, which is 64-bit everywhere. However, Win32 executables running on Win64 are still limited to 2 GiB of process address space (or 4 GiB if they were compiled with IMAGE_FILE_LARGE_ADDRESS_AWARE).
"That's why you see commercial jets dump or burn off fuel before an emergency landing."
Landing weight is a concern. However, they also dump fuel so there's less fuel to burn if the fuel tanks are breached in the landing attempt. In emergency landings that actually make it to the "landing" stage, fire and smoke kill more people than blunt force trauma due to impacts. In emergencies, aircraft without fuel dumping systems will prefer to circle, to burn up fuel with the engines. Only if they must land immediately will they skip that. (Contrary to expectations, not all emergencies require immediate landing. Stuck landing gear, for example.)
"9/11 sucked, but it wasn't a national emergency. It was an emergency in NYC, D.C. and a Pennsylvania field."
We know that now. But at the time, I don't think it was especially obvious, especially given that the ultimate target of the UAL 93 hijackers presumably wasn't a field in PA. The government shut down all public US air traffic for three days, remember?
I think it's more likely that there was simply no useful message that could be put out on the EAS. Broadcast operators had already independently preempted practically every civilian broadcast channel for news programming. More to the point, there wasn't much individuals could do about it. In, say, a biological attack, you can give instructions like "boil water; avoid fresh food". What could have been said on 11 Sep 2001? "Planes are flying into buildings -- everybody duck!"?
Slashdot Mirror
"Telling application developers to use a database is bullshit."
I'm not telling application developers to use a database; I'm explaining what's driving a remark others have made. Application developers can use whatever suits their need. If a database is what they want, then sure, use one. If something else is better, use that.
"A open-write-close-rename sequence merely asks for atomicity without durability, something that's perfectly reasonable."
You may think it's perfectly reasonable, but you're asking for atomicity across multiple operations. So really want you want is transactions. To the best of my knowledge, neither Linux, nor Windows, nor Mac OS X, nor any of the BSDs, offer transactions in the filesystem layer. I've always thought such would be a good idea, but I don't think it exists.
Further, even if filesystem transactions did exist, the application would have to request it. There's no way for the OS to magically divine what an application considers a filesystem transaction to be; the application has to tell it. So the order of operations would need to be begin-open-write-close-rename-commit.
"all the application wants is for either the old version of a file or the entire new version to appear on a reboot"
Then the application should call fsync on the new file before removing the old one. That's the only mechanism the POSIX specification provides to guarantee something has been committed to disk. It may be more than the application really wants or needs, but it's all POSIX provides. One can argue POSIX should do more, of course. More on that below.
"He doesn't care at the instant of the rename whether that replacement has been recorded on disk ..."
Actually, yes he does, because the operation he's requesting is to destroy the only known-good file. It's not the OS's fault that the programmer didn't actually make sure his new copy was good before he destroyed the old one.
The programmer may have intended for the OS to make sure the new copy was good, but he never asked it to do so (i.e., with fsync).
"asking for that same durability in a multi-file configuration setup is just stupidly degrading performance."
So, baring new system calls for filesystem transactions, what should the filesystem do, then? Serialize all I/O operations? Now you're destroying the I/O scheduler and killing multitasking performance.
Maybe there's another option here that I'm not seeing.
"open-write-close-rename is saying something fundamentally different from open-write-fsync-close-rename"
Yes, one is safe, the other is unsafe.
I think the problem here is you're implying semantics which don't actually exist in the OS or it's interface specification. Programming by "gee I really wish things worked this way" is a bad way to do things.
Now, maybe you want to make the argument that the OS should provide transactions. I'd even agree with you. But one doesn't write code based on a feature request; you write code based on what the system actually does.
Or am I missing something else?
"Nope, it writes a new file and then renames it over the old file, as rename() says it is an atomic operation - you either have the old file or the new file. What happens with ext4 is that you get the new file except for its data. "
Two things are happening:
(1) KDE is writing a new inode.
(2) KDE is renaming the directory entry for the inode, replacing an existing inode in the process.
KDE never calls fsync(2), so the data from step one is not committed to be on disk. Thus, KDE is atomically replacing the old file with an uncommitted file. If the system crashes before it gets around to writing the data, too bad.
EXT4 isn't "broken" for doing this, as endless people have pointed out. The spec says if you don't call fsync(2) you're taking your chances. In this case, you gambled and lost.
KDE isn't "broken" for doing this unless KDE promised never to leave the disk in an inconsistent state during a crash. That's a hard promise to keep, so I doubt KDE ever made it.
A system crash means loss of data not committed to disk. A system crash frequently means loss of lots of other things, too. Unsaved application data in memory which never even made it to write(2). Process state. Service availability. Jobs. Money. System crashes are bad; this should not be news.
The database suggestion some are making comes from the fact that if you want on-disk consistency *and* good performance, you have to do a lot of implementation work, and do things like batching your updates into calls to write(2) and fsync(2). Otherwise, performance will stink. This is a big part of what databases do.
As someone else suggested, it's perfectly easy to make writes atomic in most filesystems. Mount with the "sync" option. Write performance will absolutely suck, but you get a never-loses-uncommitted-data filesystem.
I'd dispute your claim that hierarchy is at a disadvantage for defense. Loose groups are good for offense because you can't just counter-attack the command and control structures. But for building a foundation for attack, you want something strong and solid.
I say "your claim" because while I haven't read that RAND report in completeness, a cursory examination suggests that they don't particularly favor an unstructured defense.
Er, yes, I should I have written, "The NSA has given up on controlling crypto through legislation". Sorry for the unclarity.
"Wait, NIST? You mean the guys who sit around and define the meter and mile and kilogram? ;)"
The National Institute of Standards and Technology, yes. Check out the NIST Computer Security Resource Center: http://csrc.nist.gov/ It's actually good stuff, but again, redundant with the eleventeen other US Federal agencies publishing guidance. Confusion over authority helps nothing, least of all security.
Oh, and BTW: It's actually the BIPM that defines the SI units like meter and kilogram. (BIPM = Le Bureau international des poids et mesures, the International Bureau of Weights and Measures, headquartered in France.)
"Disobeying a corrupt director won't get you hanged."
In fairness, disobeying a corrupt order will generally not lead to hanging. It likely will lead to a Court Martial, but if the order truly was corrupt, you'll be let off. Not that "I don't agree" does not make an order corrupt.
Still, I think you do make a fair point, so touche. Generals do command large forces with large weapons. The DCI commands a rather smaller force, most of whom don't have weapons, and most of those who do have much smaller weapons.
Of course, the CIA used to operate its own air force (the U-2 and SR-71 were originally CIA programs). Whether they still do, of course, is a matter of public speculation. :) But even then, the U-2 and SR-71 were never fitted with weapons systems. Well, not that the public knows about, anyway. Publicly, the SR-71 was intended to have the option of weapons capability; the option was simply never exercised. The neat thing about black ops is that there's always the possibility that they did something and just never told us.
"How common is it for a coup d'état to come from a minister of interior security?"
Well, since the "minister of interior security" in many authoritarian governments actually wields quite a lot of power, it's actually not uncommon. Look at the 1991 coup attempt in the USSR: That came from the KGB (Committee for State Security). The NKVD (KBG's predecessor under Stalin) likewise was the organization for administered the deaths or "disappearance" of millions of people.
But let's just look at the US (which, despite all its fault, is far from authoritarian). None of the organizations I named, aside from maybe the FBI, is concerned solely with interior security. Some of them are chartered explicitly to not be concerned with interior security.
But that itself is another fallacy: A great many security threats (I'm tempted to say the majority of them) know no border. So it's not practical to draw a line and say "this agency will only concern itself with interior threats". Sure, it would be nice to say the FBI should only concern itself with domestic cases, but the problem is that you generally don't know the full extent of the case until the case is solved.
"Except Vista and Windows 7 *don't* make Admin accounts by default."
I don't know about Win 7, but Vista prompts the user to create a new account during install. That account is assigned admin privileges. It's not even required to have a password.
As I believe is required at this point: *BZZT*, wrong, but thanks for playing!
"What bothers me is nobody seems to answer the question: "What *should* they be doing?" in a reasonable manner."
Require users to create a separate admin account from the limited user account. Require decent credentials on the admin account (e.g., non-trivial password, or biometric, or whatever). If the user also wants credentials on their limited account, require those credentials to be different vs the admin account. Require regular, day-to-day operations to be performed under the limited account. Elevate operations which can effect system stability or security to the administrator account from the limited account, without requiring a log off, user switch, command prompt, special right-click menu option, or anything else cumbersome. Require the user to present credentials before elevating.
In other words, implement security best practices that have existed in the computer industry since the 1960s.
The real killer is that UAC can be configured to do this. You can have two accounts, and have it prompt for an admin password when needed. It's just not the default configuration.
Microsoft claims they didn't go this route because they thought people were too used to running as admin all the time and wouldn't give it up. But that seems like bullshit, because Microsoft forced plenty of other unwanted changes down people's throats with Vista. Why is security somehow different?
Per-process capabilities and sandboxing are also a good idea, for things like MSIE. From what I've seen, though, either the design or the implementation is poor, because they haven't been as effective as they should at stopping things like trojans (adware/spyware disguised as legit software to get the user to install it).
The object of cybersecurity is to prevent people from interfering with out computers. The NSA's JOB is to interfere with our computers.
Actually, the NSA is charged with the security of the nation's communications, including the private sector. "National Signals Agency" would be a better expansion ("signals" including communications and computers in the GOVSEC world). Sure, they spy on everybody. How much spying they should do is a quagmire of a political debate I'm not about to involve myself in here. But they also work to make sure the nation's signals infrastructure is secure.
As I pointed out in another post, the NSA publishes a lot of security guidance. It's very well written, very real-world oriented, and public. The private sector would do well to take lessons from it.
http://www.nsa.gov/ia/guidance/security_configuration_guides/
They've largely given up on controlling crypto. Of course, that just leads one to wonder -- is that because they've recognized it as a lost cause, or because they don't need to control it to crack it anymore?
so, NSA, leave it to people who know internet
Um, yah. Do you have any real idea what you're talking about?
The NSA is full of very smart people. They employ more mathematicians and computer scientists than any other organization in the world. Their IA division is very good. They publish lot of very good, public computer security guidance. The computer world would be a more secure place if most organizations tried to adopt some of their recommendations.
Check out http://www.nsa.gov/ia/guidance/security_configuration_guides/ some time. Chances are, the computers you're using to post your mindless spiel could benefit from following the instructions there.
"There should be a focus and funding on implementing BGPSEC and DNSSEC since this is where many of the major vulnerabilities lie,"
Huh?
DNS and BGP are generally run by people who know what they are doing. While there are protocol vulnerabilities, they've historically been pretty resistant to attack. Compromises have been local and stayed local, like they should.
Compare that to the massive data breaches that major financial, health care, and government organizations have reported. Compare that to the hundreds of thousands -- if not millions -- of compromised home computers service as spam cannons and botnet members.
DNS and BGP are not nearly as big a concern as that.
"One of the key reasons that there are so many agencies is that there is a clear dividing line in US law between the military and civilian agencies. "
It has a lot more to do with historical accident than separation of powers. The agencies each formed from different power bases, with slightly different but overlapping missions, and have grown into institutions.
DHS is a *great* recent example. DoD, NSA, CIA, FBI, NRO, NCSC... what, we didn't have *enough* agencies that were already supposed to be protecting us for threats? But there was a crisis, so the existing power base creates a new organization to solve all the problems, rather than trying to fix the existing organizations.
And frankly, the whole "military" vs "civilian" thing is fairly specious. If we're worried about abuse of government power, the fact that the NSA is a nominally "civilian" agency doesn't really matter. They can still abuse their power just as well. What difference does it make that their CO is a "Director" rather than a "General"?
I should state that I'm not an anti-government nut. I just think there's too much overlap in all this. The NSA, CIA, NRO, and Army/Navy/AF intelligence should all be one damn organization. When it comes to computer security, there should be one agency with authority and one set of rules and documentation. As it is now, we've got NSA, NCSC, DISA, DSS, CIA DCI, NIST, and each service's SAPCO each with their own way of doing things! It's insane! Should I be writing my security plan to NISPOM standards, or JAFAN, DCI 6/3, or NSA SNAC, or DISA STIG, or ...? And $DEITY help you if you want to use one information system for multiple government programs under different authorities!
Hell, there shouldn't be separate field command structures for Army vs Navy vs AF vs USMC. Do away with this Joint Command bullshit and put one damn power structure in place. But holy Internet gods, you suggest merging the service branch departments, and you get treated like you just suggested burning the Constitution and making the leader of the US Communist party dictator for life in place of the President.
[citation needed] Or maybe this is "weasel words". In any case, "Says who?"
Everybody *but* DJB. And since DJB has apparently pissed off just about the entire rest of the population of the planet at this point, his pet-project ideas have just about zero chance of being adopted widespread. So, in a very real sense, DNSCurve is by definition the least-good way to secure DNS, because it will never see real adoption.
Whether or not DNSCurve has any good ideas or not doesn't matter, because DJB has burned every bridge to his own little island. And it turns out that a network that doesn't connect to anything isn't very interesting.
Samba runs as root for a few different reasons that I know of:
1. bind to privileged ports (1024)
2. set{e,r}{u,g}id for the user being authenticated
3. RPC-based system administration
If it was just the first, I bet it could prolly drop root soon after startup. If it was just the first and the second, it might be able to drop root after authenticating, since each connection gets its own process. Samba may already do some of this, for all I know. Alternatively, implementing this may be difficult for architectural reasons, which may or may be solvable via code restructuring.
But for the third, it has to run as root all the time. What this refers to is the ability to perform system administration tasks (like adding/changing/deleting users, groups, computers, etc.) via Microsoft's RPC mechanism. This is how Windows does this, and Samba supports quite a bit of it. Notably, if you're doing to support Windows domains on Samba, it needs to be able to create host OS (Unix) accounts for users and machines.
It's probably theoretically possible to develop some kind of frontend/backend layer for process privilage separation, but at that point, you're basically just implementing all the protocol work Samba has to do all over again, in an internal protocol. If you couldn't get it right the first time, I wouldn't expect this try to be much better.
Remember, Samba aims to be bug-for-bug compatible with Microsoft Windows, which means inheriting any brain damage present in SMB/CIFS. If you want a clean design, this is the wrong place to look.
"Dell, if someone calls and says they got a Ubuntu computer by mistake, just have them ship it back. "
We'll get right on that.
Sincerely,
All of Dell (we all read Slashdot, but just share this one account)
"Address way more memory in total, and way more per app"
As I've said to others: I never claimed Long Mode was useless, just overrated. If one is actually working with datasets that large, it's a huge win. And certainly Long Mode has some design improvements over Protected Mode. But architectural improvements don't trump practical concerns in my book. If my first priority was a clean architecture, I'd use a DEC Alpha. Compatibility and installed base are why we're all using 8086 descendants in the first place.
"Finally, the open source community only took a year or two to transition to perfect 64-bit support, and it's been fine since at least 2005."
A year or two? I spent significant time debugging 32-bit assumption problems with Linux on the Alpha in 1996. Not 2006 -- 1996. The problems have been out there for a *long* time.
Fine since 2005? I was just last week involved in trying to solve a 32/64-bit compatibility issue with IEEE-1394 support. Granted, the guy was using a CentOS 5 system, and CentOS doesn't adopt the latest changes as they happen. But that's because other people/software (even F/OSS) don't always adopt the latest changes either. It makes sense to wait for things to stabilize before adapting.
So I don't see the picture as so rosy. A lot of F/OSS code is okay (especially really popular things like Firefox), and things are improving all the time. But it's far from a given.
"Adobe, Microsoft... see, this is why we can't have nice things!"
No argument there.
"I cant believe you are a computer user/enthusiast."
I'm an IT management type, which means I care a lot more about actual costs and actual benefits. I'm sure that makes me non-an-enthusiast, since I'm not enthusiastic about change for the sake of "my number is bigger than your number". Sorry if that impinges your sense of self-worth.
"Lets just limit CPU speed too then."
Apples and oranges. Increasing MIPS doesn't cost anything. Well, it costs R&D, but that's factored into the processor's price. And if you're an early adopter, you'll pay dearly for the latest silicon, but those of us buying on the price/performance curve do well.
"3D modelling and animation for a living. I definitely need 64-bit"
Like I said, it has its applications. I was lumping 3D into "engineering workstation", although I realize now that probably wasn't clear to those working chiefly in the consumer space. In the business world, high-end production like that is done on a class of computers generally called "engineering workstations", though they're not that different from what you buy off the shelf at Circuit City. Better graphics cards and better tech support, mainly.
I also left out games, which several replies have said are actually using datasets large enough to care about a 2 or 4 GiB address space limit. I'm not a gamer, so I'll take their word for it. So games might be the first practical application of Long Mode in the mass-market consumer sector.
"The same goes for Music. There are lots of folks editing their own music in their basements. How about video?"
Considering that music and video NLE was being done on 32-bit platforms with "Its quite easy to make a photoshop file that eats up 2GB of ram."
Doing the math, a 24-bit color bitmap with an 8-bit alpha channel at 2 GiB works out to roughly 32,000 x 32,000 pixels. That's a big image. I'm no photographer; what's considered "high rez" these days?
"Frankly I'm for now because i'm about progress ..."
Longer, lower, wider, faster, bigger, newer... must be progress, right?
I think the big press for 64-bit is more about propping up bloated software whose development is totally out-of-control and leaks memory like a sieve. Rather than improving software development -- which would would also yield better reliability, security, performance, and compatibility -- we just keep throwing more hardware at it. That's progress for you.
"Its also about running multiple applications at the same time that demand lots of ram."
As discussed, proper support for PAE would solve the problem of a multi-process workload whose individual needs fit within Win32 but whose total memory load exceeds 4 GiB.
I normally don't reply to anons, since they usually aren't watching for replies, but you seem to know what you're talking about, and do raise some good points, so I'll make an exception. (Good for you!)
"Or they just realize the benefits of using a sane instruction set architecture."
x86_64 is not "sane", it's just less broken than i386. Take a look at the DEC Alpha architecture sometime if you really want a clean 64-bit platform. It's such a pity Intel had Compaq kill it off to keep it from competing with IA-64.
"The switch from i386 -> x86_64 is not about memory addressing. It's about alleviating the register starvation that plagues the Intel instruction set."
x86_64 is very much about virtual address word size, it's just not the only thing about it. Perhaps I do underestimate the benefit of increasing from 8 to 16 general-purpose registers. Maybe it's because most architectures have 30+ GP registers available, so it still seems like a day late and a dollar short. And as I mentioned, gains can be offset by costs. But hey, if the extra registers yield a significant performance improvement for your applications, more power to you. I'm just saying it's overrated, not useless.
"I'm not sure about this, but I read somewhere that on Windows XP and Vista, enabling DEP will disable the support for PAE."
DEP is implemented by setting the NX bit (No Execute) on memory pages containing only data. The NX bit is only available in the larger page tables you get with PAE. So DEP requires PAE.
However, workstation flavors of Win32 force all hardware address to below the 4 GiB mark, in order to maintain compatibility with drivers which assume a 32 bit physical address word. The "Advanced Server" flavors fully support PAE, allowing more than 4 GiB of RAM to be used on Win32.
References:
* http://en.wikipedia.org/wiki/NX_bit
* http://blogs.msdn.com/carmencr/archive/2004/08/06/210093.aspx
But Win i386 still limits physical addresses to under 4 GiB to keep crappy drivers from crashing the system.
"It's not Windows that does this, but the BIOS assigns these addresses. Windows simply does not relocate them, and I don't know if such relocation is possible."
Such a relocation is indeed possible, if your hardware supports it. Actually, what is typically done is that non-RAM hardware stays below 4 GiB, and any displaced RAM is moved to locations above 4 GiB. Google "memory hoisting".
All this 64-bit support is tricky, because for it to work:
* CPU has to support it (but most do, these days)
* Core logic chipset has to support it (ditto)
* Motherboard OEM had to actually run traces for it (varies)
* BIOS has to not screw things up
* PCI stuff has to support DAC (Dual Address Cycle)
* Device drivers have to be able to cope with 64-bit addresses
* OS kernel has to support all of the above
There's lots of places for things to go wrong.
"Why should you worry about running 15+ year old [Win16] code on a new OS?"
Welcome to the world of business IT, where 30-year-old code is still in production use all over the place. :)
Long Mode also means potential compatibility issues with crappy 32-bit code.
"Can you give an example? 32-bit code doesn't even know it's running on a 64-bit OS unless it explicitly asks."
Lots of source code assumes integers and pointers are all 32 bits wide. Recompiling for a 64-bit platform uncovers all sorts of bad assumptions. Was a huge problem in the *nix world when 64-bit platforms arrived on the scene. Now it's a huge problem for the 'doze world.
Only applies to source recompiles, of course, but if you're going to target i386 for all your applications, why bother with a 64-bit platform? A chicken-and-egg problem, to be sure.
"Wow... Just enough knowledge to be dangerous.."
[insert vague insult on your knowledge or ancestry here]
"There is a performance penalty and it is a hackish way of solving the problem."
A good portion of the performance penalty is already taken due to DEP, which needs the NX bit, which is only available in the larger page tables PAE provides. So PAE is enabled, but workstation flavors of Win32 won't use memory above 4 GiB due to driver compatibility concerns.
"With certain desktop appplications, notably more advanced games, I could see the per-process limit being hit ... "
Games are not something I was considering. I'm a professional IT management weenie, so I don't get much exposure to the latest-and-greatest. (My home Wintendo PC tends to trail the curve; it's cheaper, and I don't have the time for gaming I once did). So my analysis is indeed lacking there. I'll bow to your experience in this area.
"There is a reason why distributions provided PAE-disabled kernels in x86 world."
Because certain workloads do indeed benefit from memories larger than 4 GiB, as I stated. It's not that a 64-bit architecture is useless -- hell, I was supporting 64-bit Alpha boxes running Linux back in 1996 -- it's just it's overrated. Most people use it as ammo in penis-length competitions, nothing more.
"Though you mention buggy 32-bit code having problems in long mode, I have never seen that occur in Linux or Windows."
It may not be common, depending on what you're doing. I address this briefly in my cousin post here:
http://slashdot.org/comments.pl?sid=1087813&cid=26408607
"I haven't run into 16-bit applications in an eternity though."
Not everyone does. It's depressingly common in the business world, though. Portions of Intuit QuickBooks were still using Win16 code three years ago, which was the last I touched that piece of crap. We've got an ERP system at work that's full of Win16 modules, too.
I expect, with the big push on for Win64 (for whatever reason, be it real performance or chest-thumping), code modernization is (or will be) becoming more of a priority for publishers. Which is certainly all to the good.
FYI, PAE doesn't get you anything much on workstation flavors of Windows, and the /3GB switch has a number of issues, too. For more information, see my cousin post here:
http://slashdot.org/comments.pl?sid=1087813&cid=26408529
"However, I've not run into any troubles using linux x86_64 with common software over the past three years. "
You're correct for most modern, Open Source applications. And plenty of others, too.
However, if you're dealing with older software that hasn't seen widespread adoption, a lot of it assumes integers and pointers are 32 bits wide. Such software is more common in niche environments, such as scientific, university, lab, and company-internal systems.
And if it's binary-only stuff, it's a whole 'nother ball game. Adobe Flash is the canonical example. They're still "alpha test" for Linux x86-64, and it was a browser-crash-in-a-box last I tried it. (Not that the i386 flavor of Flash is much better.)
If you're lucky enough to be able to run 64-bit clean everywhere, more power to you. :)
int69h wrote: "I can't believe you left out the fact that general purpose registers are doubled from 8 to 16 under long mode."
Um....
DragonHawk wrote: "equally possible performance gains (instruction architecture improvements such as more general-purpose registers)"
(Emphasis added.)
"There IS an OS boot string to let processes address up to 4Gb of RAM (or more)..."
No. Not for Win32.
There is the /3GB switch. This enables what Microsoft calls 4GT (4 gigabyte tuning). It changes the kernel/user split from 2/2 to 1/3. However, applications have to be compiled with a particular option (IMAGE_FILE_LARGE_ADDRESS_AWARE) to use it. Further, it robs the kernel of memory it might need for other things, so it's not a no-brainer. It's mainly useful if you're going to be running a single large application on the computer (e.g., Exchange Server). If you're running a multi-process workload, you're often better off giving the kernel its memory. And you're still limited to a 4 GiB virtual address space.
There is the /PAE switch. PAE = Physical Address Extension, which changes the physical address word size from 32 bits to 36 bits. This will let the processor address up to 64 GiB of RAM. However, you're still limited to a 4 GiB virtual address space. It's useful for a large multi-process workload. For example, a machine with 8 GiB of RAM can run several large tasks, each task using up to 2 or 3 GiB of memory.
Further, on the "workstation" versions of Windows (2000 Pro, XP, Vista), the /PAE switch doesn't actually increase the amount of physical hardware address space the operating system will use. It does enable PAE, but Windows still ignores physical addresses above 4 GiB. Also, PAE will already be enabled on XP SP2 and Vista, to get the NX bit.
There is also AWE (Address Windowing Extensions). This is not an OS boot switch; it is a collection of system calls. AWE is just bank switching all over again (like the ancient MS-DOS EMS). To obtain more than 2 (or 3) GiB of primary storage (memory), an application can switch pages of memory in and out of its address space. However, it cannot access pages not actively mapped to its address space, so the application basically has to do its own memory management. Ick.
*None* of this applies to Win64, which is 64-bit everywhere. However, Win32 executables running on Win64 are still limited to 2 GiB of process address space (or 4 GiB if they were compiled with IMAGE_FILE_LARGE_ADDRESS_AWARE).
References:
* http://msdn.microsoft.com/en-us/library/aa366778(VS.85).aspx
* http://msdn.microsoft.com/en-us/library/aa366796(VS.85).aspx
"That's why you see commercial jets dump or burn off fuel before an emergency landing."
Landing weight is a concern. However, they also dump fuel so there's less fuel to burn if the fuel tanks are breached in the landing attempt. In emergency landings that actually make it to the "landing" stage, fire and smoke kill more people than blunt force trauma due to impacts. In emergencies, aircraft without fuel dumping systems will prefer to circle, to burn up fuel with the engines. Only if they must land immediately will they skip that. (Contrary to expectations, not all emergencies require immediate landing. Stuck landing gear, for example.)
Sources:
* http://en.wikipedia.org/wiki/Fuel_dumping
* http://www.aerospaceweb.org/question/planes/q0054a.shtml
* http://www.aerospaceweb.org/question/planes/q0245b.shtml
* http://www.aerospaceweb.org/question/planes/q0245a.shtml
"9/11 sucked, but it wasn't a national emergency. It was an emergency in NYC, D.C. and a Pennsylvania field."
We know that now. But at the time, I don't think it was especially obvious, especially given that the ultimate target of the UAL 93 hijackers presumably wasn't a field in PA. The government shut down all public US air traffic for three days, remember?
I think it's more likely that there was simply no useful message that could be put out on the EAS. Broadcast operators had already independently preempted practically every civilian broadcast channel for news programming. More to the point, there wasn't much individuals could do about it. In, say, a biological attack, you can give instructions like "boil water; avoid fresh food". What could have been said on 11 Sep 2001? "Planes are flying into buildings -- everybody duck!"?