Very little: Univel was a joint venture between AT&T and Novell; they occupied the second floor of the Sandy, UT facility, just off 106th South just off I15 (I worked on NetWare for UNIX on the third floor of the same building).
Ray was already pretty much out by then; he was still chairman of the board, but even then he was known to write himself notes when travelling so that he'd know what city he was in when he woke up in the morning.
Novell's day to day operations were handled by "the office of the president", which was Ad Rietveld (former WordPerfect president and CEO), Mary Burnside (Novell's COO up to that point) and Jim Tolonen (Novell's COO up to that point).
After the purchase of USL, Noorda's legacy, "coopetetition" - start several groups working on solving a problem at the same time, and run with whatever ends up actually being best - was pretty much all but gutted by the USL management.
Bryan Sparks and Ransome Love actually went off and started Caldera with their own funds by selling a number of large parcels of land they had bought a while before that, and it was only after they had kicked in their own money that Noorda came along with Canopy and funded them. They left because there was a lot of NIH going around after the USL purchase, and they weren't allowed to work on the product they wanted to build, so they started a skunk works internally, and went outside when the former USL management started getting all competing projects cancelled.
I think there's also an as yet undiscussed "Fetal Internet Syndrome"...
My friends new Windows box is addicted, and it was never exposed, new from the store... computers with this syndrome have serious mental lapses if they can't get on the Internet to chat with Microsoft in the first thiry days after being turned on, and on a regular basis after that.
I'm pro spaceflight, I'm pro spece exploration, and I'm pro a space elevator.
But if you think NASA won't invest money in a folly, then can you please explain why the DC-X was built 1/3 size so that it could never get to orbit, and the SCRAM-jet was built as a scaled down model that could never carry anything or do useful work, just like the DC-X?
Back in the 50's and 60's, we didn't build anything that wasn't man rated: if it flew, then you could produce a copy of it and fly it for real.
I suppose we could blame some of this "let's build a cheap version" on our ability to build RPV's or even automated flight control systems, instead of needing to stick a human being in the thing as a guidance system, but when you aren't building something that can achieve the eventual mission goals, then whatever youbuild - won't.
I don't know if I believe in the "evolution instead of revolution" philosophy when it comes to doing new things - if Columbus thought that way, he'd have incrementally explored larger and larger circles to find all the islands between Spain and the East Indies, and would have died of old age before he got far enough along that he "found" Iceland.
Robotic systems are good for finding what you expect; to find what you *DON'T* expect usually takes human judgment. Lofting one planetologist on a one way flight to Mars with some lab equipment and a small set of hand tools recognizable to a geologist or rock hound on Earth would probably yield more data than all of the robotic Mars probes we have, or could ever, get to Mars.
Just like the information we got from the moon by sending people to putter around there, and then bring *the right* rocks back (which rocks are right is also a human judgement call that can't be emulated by a robot).
(And yead, I said "one way" - there are plenty of people who would jump at the chance, even thoughit meant they'd probably die there).
Here is a quote from EPA documentation to that effect:
"In a vehicle with a properly functioning oxygen sensor, the feedback control of the air/fuel ratio acts to defeat the purpose of adding oxygenate to the fuel. The vehicles that will benefit the most from oxyfuels are high emitters, generally older vehicles or newer vehicles with broken emission control systems (PRC, 1992)"
"To understand why I created OpenDNS requires a little background. I'd moved to San Francisco after graduating from Washington University in St. Louis, and was managing EveryDNS, a popular and reliable DNS management service which I started five years ago."
A small correction; Chernobyl happened because of very bad reactor design (the four reactors were RBMK reactors). It was inherently unstable. because it used water moderation, and as the water converted to steam, it had a runaway power increase (this is called a positive void coefficient), leading to the steam blowing the top off the building.
Reactors don't have to be built that way, and not all designs are intrinsically risky. For example, a Pebble bed reactor http://en.wikipedia.org/wiki/Pebble_bed_reactor can't melt down, and is self-moderating due to neutron dopplering.
Even so, Japan, the only country which has ever had an atomic bomb dropped on it by a foreign power, has a lot more to fear from nuclear energy than the U.S., and they have 23 breeder reactors and 30 other reactors that commercially generate a little over 25% of Japans total electrical needs. Their current plans are to increase this by 30% by 2011 as part of their compliance with the Kyoto accords on CO2 emissions.
If you read US Patent # 4,835,433, you'll see that a device about the size of a keg of beer will crank out about 7500 W for 29.1 years, if you put a small amount of Strontium-90 in it (one gram - about 2mm of 16 gauge wire worth of material). Since Strontium-90 is generally considered nuclear waste these days, it's very easy to "mine" it out of our current waste dumps. If you want something smaller, then something the size of a "D" battery will crank 75 W for the same amount of time.
Even if you don't want to carry it around with you (it emits only alpha and beta particles, not gamma, so it doesn't actually require heavy lead shielding), you can use the electricity generated to generate fuel for use in fuel cells, if you'd rather carry around something combustible with you, instead of a keg of beer with neck-bolts.
What really annoying about the whole nuclear fear in the U.S. is that it's really a very green source of energy. You get more radiation released into the atmosphere from a coal-fired plant, not to mention the sludge for your lungs to filter ut of the air. If the U.S. would follow the lead of France and Japan, and build breeder reactors, and did fuel cycling like Japan does, we could stop digging for more fuel (it'd be generated as a by product of the reactor running), and it'd never be in a form where it could be used to build a nuclear weapon.
Sorry; I wasn't that impressed... the entire article read like a hard-sell pitch for all-in-one security appliances. And it turns out one of the authors is the V.P. of marketing for a company selling a range of all-in-one security appliances.
I'd actually think that everyone going the recommended route would end up in the same boat as the current monoculture of point product that they complain about. Now, instead of being compromised because we're all running the same code, we get compromised because we're all running the same security appliance, with the same flaws.
I'd actually rather see a diverse and heterogeneous set of defenses to prevent large scale compromises working against everyone, and the economy of throwing everything into a box, rather than loading a bunch of diverse software strikes me as a false one.
The same arguments that make me want to run a MacOS X box or a FreeBSD box or a Linux box instead of some other platform with well known vulnerabilities make me *not* want to run the same appliance box in front of my network that everyone else is running, too.
Maybe I'm just jaded, and have heard "best of breed" one too many times. 8-(.
It's up to him to set the fraud alert because he's the only one allowed to do it. It's also a conscious decision to make certain transactions more difficult for the period of the alert, which is not something you'd want someone else to be able to do "for" you.
You can place a fraud alert on your credit report. An initial alert does not require a police report, and lasts for 90 days. During this time, you may end up having to jump through additional hoops to obtain new credit.
The easiest way to put an alert is to use the online form at Experian; alternately, you can call any of the credit reporting agencies to also set up an alert, if you want to do it by phone, instead.
The direct link for the Experian site to do this is:
As *the* former Novell/USG employee who rescued the contents of the UNIX International server in 1994 when it went defunct, and saved the electronic copies of the ELF 1.0, DWARF 1.0, Spec1170 (the Single UNIC Specification), TET, ETET, and other documents from extenction before the UI FTP server (hosted in Sumit, NJ) was taken offline (all documents were kindly rehosted for FTP by Ken Germann of Digiboard, Inc., and Utah State University CS Department), I call BS.
I received verbal permission for making the contents of the archive available from USL's representative to TIS prior to the mirroring. I specificallly called on the phone for this, even though it was a publically acessible FTP site, just to be sure.
This can be corraborated by Daren Davis, a former Univel then Novell/USG then Caldera employee, and by others who worked at Novell at the time (Jim Freeman knew about the archive, as did Dan Grice, Ron Holt, Bryan Cardoza, and a number of others, some of whom ended up involved with Caldera, and some who didn't).
The orginal 1.0 ELF specification came primarily out of work by engineers at Intel. The 1.2 specification, which *did* have significant work done by USL, was done under the auspices of TIS, with the *explicit* understanding that the result would be available as an ABI standard for all.
ftp://ftp.digibd.com/ USA GMT -6 25-Jan-95 belal@sco.com (Bela Lubkin> {posting} DigiBoard keng@digibd.com Server : http://www.digibd.com/ Files : Digiboard (digifax, digiline: drivers, isdn); pub: HP4laser (lp
model for autohandling of PCL/PostScript jobs), SCO-ports,
uiarchive (archive of the defunct Unix International effort),
unixware, WWW
Note that this is just an excerpt from a Usenet posting for the site listing for the site - the mirroring occurred in early 1994 (January, if I remember correctly), and the UI servers were defunct as of Mar 1994, when the mailing list archives were moved over. Novell acquired USL from AT&T in Jun 1994.
An ironic, IMO, thing to note in the posting above is that the location of the archive is being disseminated by an SCO (the real SCO) employee.
As long as the tapes weren't being used for commercial profit, it was effectively a free-for-all, to the point of them setting up a "taper's area" to allow their own sound crew to have access to the area where they'd need to set up their equipment for the best sound for the concert.
There were/are a number of other bands that had/have the same practice: Rat Dog, The Other Ones, etc..
The only safe language to code in would be assembly, and you'd have to write all the code yourself, unless you wanted to be liable for the output of the compiler or the libraries you linked to.
Shared libraries and loadable modules couldn't be trusted, since if your application had them, someone else could substitute a different library or module, and your code would never know the difference. If you added checking mechanisms to *for sure* know the difference yourself, you'd have to trust the FS.
All applications would have to be embedded applications, since you couldn't trust an OS vendor - what would happen if the system call behaviour was changed by the OS vendor? What if it wasn't by the OS vendor - what if the OS vendor trusted third party companies to write drivers?
What about firmware? The OS trust the firmware to load it! What if the firmware changes, or isn't exactly the firmware you expected?
What about the hardware? What if the instruction set on the CPU changes? You'd have to tie your software to particular hardware; historically, for example, 6502 processors were mask-programmed, and had "in between" op codes - they'd do something, but what the side effects were depended on the chip stepping. Your code could work in testing, but not in production unless you guaranteed the same chip lot, since it might be working as a result of a serendipitous error that was fixed in the next chip.
Down this road, you'd only ever have software sold by people who made the OS sold by the people who wrote the firmware sold by people who built the hardware... and maybe the components of the hardware themselves.
So basically you'd have... what... nothing left, but IBM from the 1950's?
It is a trivial experiment to initially cache the vp for/dev/null and/dev/zero, and then turn any reads or writes from either around immediately in the first function called out of the sysent[] table as soon as you see an fd pointing to one or the other, and never enter into the rest of the kernel. Then you can run the lmbench "system call speed" tests, with everything *but* the call site overhead factored out.
The real problem here, though, is the perception that system call trap speed is actually somehow very important. This has grown out of the Linux community.
Part of it is Larry McVoy's benchmark suite, designed to make Linux look better than other OSs; the perception that system call speed is important is based on the idea that since it can be measured, making it small as possible is worthwhile. As evidendence that this is actually jingoistic, the previous "null system call" implementation in LMBench was actually getppid(), and prior to that, it was getpid() (the result of getpid() is cacheable in user space in Libc). As other OSs have started turning the calls around faster, other calls have been selected to keep Linux ahead.
The second part of the problem is deeper, and goes to how people program software being influenced by their execution environment, and their perception. This is more problematic. Whether it's the idea that it's OK to not bzero() a sockaddr_in before using it in a call to connect() (which works on Linux, but fails on most BSD derived systems because of the "mutual connect" case in the TCP state machine that isn't accounted for in the Linux implementation), or it's the idea that thread creation or system calls are "free", and therefore not to be avoided, or whether its something else, it ends in bad code.
My canonical example for this is MySQL's client libraries, which end up making multple system calls (3 of them) per transaction, when they could get by with a single system call simply by buffering their data per client connection, rather than per thread in the MySQL server. This simple change would amount to a huge performance improvement on most OSs; Linux itself would see perhaps a 5% performance improvement from the change. But it would be an improvement. Yet people keep pointing to MySQL as a benchmark, when what they are measuring is actually a design problem in the database, not the OS on which it's running.
The problem is that most people don't change code, once they get it to the point that it works well enough for their initial uses - and short of someone doing a deeper port than just a trivial "get it compiling and running" type port, you're not going to see the performance on *any* platform that wasn't the initial platform where the code was written and tuned. Or to put it another way, the person most capable of tuning the code is almost never going to be the person moving it to a new platform; so platform assumptions built into the implementation of the code - or worse, the design of the code - are going to bite everyone that moves it to a new platform.
For thread creation - well, you know, there's a good reason that Apache pre-spwans anonymous workers, and applications that don't are probably assuming that thread or process creation is "free" or close enough that they don't care.
Personally, I'm not that impresed with benchmarks that purport to measure kernel performance; other than I/O, where most of the time is spent waiting on whatever you're talking to, well written applications tend to spend their time in user space; I've heard that on MacOS X, it's usually more than 80% of the time in user space, and for multimedia or compute bound applications, it can get a lot higher than that.
Microbenchmarks have their place; they are useful for comparing against yourself, and for detecting regressions before they become entrenched. But they aren't very useful for anything else, and exspecially not for comparing one OS to another.
Most laptops are seriously limited by form factor of the particular cards it's expected to accept in such a slot - in general, they are not full sized cards, but as small as they can make them, and potentially oddly shaped, if they are on an internal connector.
The other limitation that a card could throw way off kilter - particularly, a display card replacement - is the thermal budget. You're already seeing vendors selling laptops that *must* have power management to enable them to run within their thermal budget when the ambient temperature is higher than some minimum below which there is no throttling required (say 60 degrees Fahrenheit).
Putting in a very large, high thermal output graphics card, even if it would fit (see first paragraph) will at best blow your thermal budget; at worst, the heat pipes for the card, even if they happened to hput the hot spots in the same place, would be unlikely to be able to dissipate the load - either because they are undersize, or because they share their heat sinks with other components that are already pushing them at their effective limits.
So I seriously doubt you are going to have a lot of component upgradeable laptops available. There might be one or two niche vendors that over-engineer their thermal envelopes so they can handle upgrades, but... expect them to be much heavier in general, for the "generic" heat piping and sinking, and to potentially be noisier, if they also end up with higher air flow fans to cool above the expected default configuration load.
I don't think the "Road Warrior" market is big enough to support someone like a Dell or an Apple building and marketing one of these monsters.
When I first proposed KSE, my proposal was that all system calls become asynchronous - you dispatch the system call. Then, if you wanted POSIX semantics, you suspended yourself until the result was available.
The intent was to implement all of the POSIX blocking semantics at the Libc layer, and all the operational semantics at the kernel layer, and to permit any number of dispatches to occur concurrently.
The way you implement multithreading in this environment is to use call-conversion scheduling: you trade a normally blocking system call for a non-blocking system call plus a context switch. This basically gets you multithreading for free.
The intent of this approach is to utilize your full process quantum, rather than giving it away and suffering an unnecessary context switch overhead, while you still had work pending that could be done in user space within the same process.
In one posting, I put it like this: "If a kernel gives me a quantum, it's *my* damn quantum, and I'll use as much of it as I can, and if I can't use any more,*then* I will yield to a voluntary context switch".
The way you obtain SMP scalability (which was *NOT* the original reason threads were invented in the first place, BTW, since they predated commercially viable SMP system by a long ways) is by permitting multiple processors to return to user space on completed async system calls.
Intelligent readers will not that by not giving away the quantum you were given, you basically get a form of CPU affinity thrown in for free, without any modification to the kernel scheduler, up to the point where you would context switch to a process other than yourself, and cache-bust/TLB-shootdown anyway. This was not a bad idea.
-
What happened instead was an implementation of SA (Scheduler Activations). They kept the KSE name. I came up with it initially - "Kernel Schedulable Entitites" - because I didn't want people to be thinking about solving the problems we intended to solve in a way that was constrained by the ideas that would carry over from using words like "activations" or "threads" or whatever. Semantic loading constrains free thought on technical issues a heck of a lot more than people give it credit for.
But SAs fell far short of my intended vision for the original implementation, a vision I could not implement on my own without buy in from the rest of the FreeBSD community.
-
Once we got buy-in that we were going to do *something* in this area, we had a big meeting. It was hosted at Whistle Communications, where Julian and I and others worked, and where we tended to host BAFUG meetings. Jason Evans and others attended.
I was unfortunately unable to sell my async call gate approach to the problem ("too many changes"), and a compromise was worked on scheduler activations, and a user space thread scheduler that would cooperate with the kernel scheduler.
Compared to what we ended up with, the changes required for the async call gates would have been a lot less code. But I fully admit: my suggested approach would have been impossible to implement incrementally - it would have been all or nothing, and stepping over that threshold would have cost a lot. I failed to sell it adequately, and can only fault myself.
-
Realize that this was not a bad compromise, given the technology at the time: context switches were murder, and crossing the user/kernel protection domain was a heck of a lot more expensive than it is on todays hardware. Also, the vast majority of SMP Intel boxes available in 1996/1997 were at best 2 processor boxes (I still have my dual P90 ASUS box).
Later, the expense of scheduler activations became plain, but it was still not too bad, until things like TLS - "Thread Local Storage" - and other POSIX semantics changes started to make things more painful.
-
Meanwhile, FreeBSD got thread reentrancy work done in its kernel, and a separation of address spaces and contexts, that it would have needed to have, no matter what threading approach was used. So KSE's, even implements as the were, instead of how I had originally envisioned them, was well worth it.
There is a huge amount of mainstream coverage of this.
NB: I listen to both liberal and conservative radio talk shows on and off, and touch base with both liberal and conservative press when I have the time to do so. In the interestes of full disclosure, I'm pretty jaded about our media.
In general, the liberal portions of the press are formally outraged, but are conveniently ignoring Title 18 USC 2701 (c)(1) http://www.usdoj.gov/criminal/cybercrime/usc2701.h tm, which permits the corporations to *voluntarily* disclose these records to anyone they want, including the estranged husbands of battered women, if it suits them.
While the conservative portions of the media are protesting that the operations are perfectly legal, but not pointing to this as a voluntary disclosure (the companies involved were in fact paid $$$ to "volunteer" the records), and are themselves ignoring the fourth ammendment issues and the common law privacy rights issues surrounding the constitutionality of Title 18 USC 2701 (c)(1) in the first place.
Meanwhile, everyone is ignoring the fact that there are two sets of surveillance operations: one, which broke in the news months ago, having to do with actual communications intercepts, and this more recent one, which has to do with collection of information for traffic analysis (and from that, subsequent social network analysis built on top of that).
The liberal side is trying to paint this traffic analysis as if the "communications records" in question were actual recordings of conversations, rather than endpoint identification and call duration; the conservative side is still defending everything as being perfectly legal and above board (techincally, they are correct about the legality, from my reading of the laws, but whether or not this is "above board" really relies on whether the laws being used to collect the information are in fact constitutional).
Nobody is addressing whether or not the Patriot Act provisions mean this same information can be used by law enforcement for non-terrorist related criminal investigations, or what the implications are for tarring people with the same brush, if they happen to have a black sheep in their family who keeps in touch, and therefore associates them with a legitimately identified criminal social network.
I also haven't heard anyone talking about whether or not standard traffic analysis fuzzing techniques are being utilized by The Bad Guys(tm), like intentionally identifying phone numbers associated with groups, and calling them from within multiple points in a covert terrorist network, to link the networks together, and therefore either (a) hide in plain sight, or (b) broaden the target list sufficiently that the investigative requirements would be prohibitive. All it would take is different people calling from the same phone number to the same network connection point with a "wrong number" and being excessively chatty to get the connection time up.
Nobody in the media is talking about what happens when these records, if they are shared, are mined after the fact to provide overwhelming circumstantial evidence in the pursuit of a personal vendetta against a private citizen by a minor official.
All in all, it's a standard media feeding-frenzy, with a lot of noise, no one touching any of the important issues (might kill the goose that laid the golden egg, doing that...), and both sides posturing in no provable or disprovable way that might end up stopping the fun before the subject has been milked for all the public attention that they can wring out of it.
Hope that answers your question.
FWIW: I think my cynicism here is fairly representative of most average "man on the street" U.S. Citizens. Don't take the actions of our government, or the distorted cartoons of those actions, as represented by our media, at face value, and don't take them as being representative of U.S. Citizens in general; we aren't the jackasses our media makes us out to be.
Slashdot Mirror
Very little: Univel was a joint venture between AT&T and Novell; they occupied the second floor of the Sandy, UT facility, just off 106th South just off I15 (I worked on NetWare for UNIX on the third floor of the same building).
Ray was already pretty much out by then; he was still chairman of the board, but even then he was known to write himself notes when travelling so that he'd know what city he was in when he woke up in the morning.
Novell's day to day operations were handled by "the office of the president", which was Ad Rietveld (former WordPerfect president and CEO), Mary Burnside (Novell's COO up to that point) and Jim Tolonen (Novell's COO up to that point).
After the purchase of USL, Noorda's legacy, "coopetetition" - start several groups working on solving a problem at the same time, and run with whatever ends up actually being best - was pretty much all but gutted by the USL management.
Bryan Sparks and Ransome Love actually went off and started Caldera with their own funds by selling a number of large parcels of land they had bought a while before that, and it was only after they had kicked in their own money that Noorda came along with Canopy and funded them. They left because there was a lot of NIH going around after the USL purchase, and they weren't allowed to work on the product they wanted to build, so they started a skunk works internally, and went outside when the former USL management started getting all competing projects cancelled.
-- Terry
``"Computer, what are the nearest sources of gold-pressed latinum" yields no results, for me.
Well there's your problem. You asked it for sources of GPL, not where you could acquire it.''
Of course, with GPL, you do get the sources... (badda-bing).
-- Terry
I think there's also an as yet undiscussed "Fetal Internet Syndrome"...
My friends new Windows box is addicted, and it was never exposed, new from the store... computers with this syndrome have serious mental lapses if they can't get on the Internet to chat with Microsoft in the first thiry days after being turned on, and on a regular basis after that.
-- Terry
Don't get me wrong...
I'm pro spaceflight, I'm pro spece exploration, and I'm pro a space elevator.
But if you think NASA won't invest money in a folly, then can you please explain why the DC-X was built 1/3 size so that it could never get to orbit, and the SCRAM-jet was built as a scaled down model that could never carry anything or do useful work, just like the DC-X?
Back in the 50's and 60's, we didn't build anything that wasn't man rated: if it flew, then you could produce a copy of it and fly it for real.
I suppose we could blame some of this "let's build a cheap version" on our ability to build RPV's or even automated flight control systems, instead of needing to stick a human being in the thing as a guidance system, but when you aren't building something that can achieve the eventual mission goals, then whatever youbuild - won't.
I don't know if I believe in the "evolution instead of revolution" philosophy when it comes to doing new things - if Columbus thought that way, he'd have incrementally explored larger and larger circles to find all the islands between Spain and the East Indies, and would have died of old age before he got far enough along that he "found" Iceland.
-- Terry
"Those areas included ... sorting music tracks by their genre, artist and album attributes."
Hi. I've invented third normal form. Pay me.
Always remember, I'm the only one allowed to index and sort database records by individual field contents, without a royalty.
-- Terry
Robots are a poor substitute for people
Robotic systems are good for finding what you expect; to find what you *DON'T* expect usually takes human judgment. Lofting one planetologist on a one way flight to Mars with some lab equipment and a small set of hand tools recognizable to a geologist or rock hound on Earth would probably yield more data than all of the robotic Mars probes we have, or could ever, get to Mars.
Just like the information we got from the moon by sending people to putter around there, and then bring *the right* rocks back (which rocks are right is also a human judgement call that can't be emulated by a robot).
(And yead, I said "one way" - there are plenty of people who would jump at the chance, even thoughit meant they'd probably die there).
-- Terry
Parent is correct about oxygenated fuels.
Here is a quote from EPA documentation to that effect:
"In a vehicle with a properly functioning oxygen sensor, the feedback control of the air/fuel ratio acts to defeat the purpose of adding oxygenate to the fuel. The vehicles that will benefit the most from oxyfuels are high emitters, generally older vehicles or newer vehicles with broken emission control systems (PRC, 1992)"
http://www.epa.gov/otaq/regs/fuels/ostp-1.pdf
-- Terry
FWIW: EveryDNS is the same guy.
o pendns/
http://blog.opendns.com/2006/06/28/why-i-started-
"To understand why I created OpenDNS requires a little background. I'd moved to San Francisco after graduating from Washington University in St. Louis, and was managing EveryDNS, a popular and reliable DNS management service which I started five years ago."
-- Terry
A small correction; Chernobyl happened because of very bad reactor design (the four reactors were RBMK reactors). It was inherently unstable. because it used water moderation, and as the water converted to steam, it had a runaway power increase (this is called a positive void coefficient), leading to the steam blowing the top off the building.
Reactors don't have to be built that way, and not all designs are intrinsically risky. For example, a Pebble bed reactor http://en.wikipedia.org/wiki/Pebble_bed_reactor can't melt down, and is self-moderating due to neutron dopplering.
Even so, Japan, the only country which has ever had an atomic bomb dropped on it by a foreign power, has a lot more to fear from nuclear energy than the U.S., and they have 23 breeder reactors and 30 other reactors that commercially generate a little over 25% of Japans total electrical needs. Their current plans are to increase this by 30% by 2011 as part of their compliance with the Kyoto accords on CO2 emissions.
-- Terry
Board membership is published at their web site and in the Federal Register:
c e.htm
http://www.access-board.gov/sec508/comm-finalnoti
The board consists of 39 representatives from industry and disabilities organizations:
I think the first poster was maybe confused about the appointment of Public members of the U.S. Access Board itself:
http://www.access-board.gov/news/members06.htm
-- Terry
Actually, nuclear is a good match for vehicles.
If you read US Patent # 4,835,433, you'll see that a device about the size of a keg of beer will crank out about 7500 W for 29.1 years, if you put a small amount of Strontium-90 in it (one gram - about 2mm of 16 gauge wire worth of material). Since Strontium-90 is generally considered nuclear waste these days, it's very easy to "mine" it out of our current waste dumps. If you want something smaller, then something the size of a "D" battery will crank 75 W for the same amount of time.
Even if you don't want to carry it around with you (it emits only alpha and beta particles, not gamma, so it doesn't actually require heavy lead shielding), you can use the electricity generated to generate fuel for use in fuel cells, if you'd rather carry around something combustible with you, instead of a keg of beer with neck-bolts.
What really annoying about the whole nuclear fear in the U.S. is that it's really a very green source of energy. You get more radiation released into the atmosphere from a coal-fired plant, not to mention the sludge for your lungs to filter ut of the air. If the U.S. would follow the lead of France and Japan, and build breeder reactors, and did fuel cycling like Japan does, we could stop digging for more fuel (it'd be generated as a by product of the reactor running), and it'd never be in a form where it could be used to build a nuclear weapon.
-- Terry
Sorry; I wasn't that impressed... the entire article read like a hard-sell pitch for all-in-one security appliances. And it turns out one of the authors is the V.P. of marketing for a company selling a range of all-in-one security appliances.
I'd actually think that everyone going the recommended route would end up in the same boat as the current monoculture of point product that they complain about. Now, instead of being compromised because we're all running the same code, we get compromised because we're all running the same security appliance, with the same flaws.
I'd actually rather see a diverse and heterogeneous set of defenses to prevent large scale compromises working against everyone, and the economy of throwing everything into a box, rather than loading a bunch of diverse software strikes me as a false one.
The same arguments that make me want to run a MacOS X box or a FreeBSD box or a Linux box instead of some other platform with well known vulnerabilities make me *not* want to run the same appliance box in front of my network that everyone else is running, too.
Maybe I'm just jaded, and have heard "best of breed" one too many times. 8-(.
-- Terry
Is that your battery, or are you happy to see me?
-- Terry
It's up to him to set the fraud alert because he's the only one allowed to do it. It's also a conscious decision to make certain transactions more difficult for the period of the alert, which is not something you'd want someone else to be able to do "for" you.
-- Terry
You can place a fraud alert on your credit report. An initial alert does not require a police report, and lasts for 90 days. During this time, you may end up having to jump through additional hoops to obtain new credit.
e ssion.do?code=SECURITYALERT
The easiest way to put an alert is to use the online form at Experian; alternately, you can call any of the credit reporting agencies to also set up an alert, if you want to do it by phone, instead.
The direct link for the Experian site to do this is:
https://www.experian.com/consumer/cac/InvalidateS
More advice available here for identity theft victims:
http://www.consumer.gov/idtheft/con_steps.htm
Hopefully, you will not need it.
-- Terry
As *the* former Novell/USG employee who rescued the contents of the UNIX International server in 1994 when it went defunct, and saved the electronic copies of the ELF 1.0, DWARF 1.0, Spec1170 (the Single UNIC Specification), TET, ETET, and other documents from extenction before the UI FTP server (hosted in Sumit, NJ) was taken offline (all documents were kindly rehosted for FTP by Ken Germann of Digiboard, Inc., and Utah State University CS Department), I call BS.
I received verbal permission for making the contents of the archive available from USL's representative to TIS prior to the mirroring. I specificallly called on the phone for this, even though it was a publically acessible FTP site, just to be sure.
This can be corraborated by Daren Davis, a former Univel then Novell/USG then Caldera employee, and by others who worked at Novell at the time (Jim Freeman knew about the archive, as did Dan Grice, Ron Holt, Bryan Cardoza, and a number of others, some of whom ended up involved with Caldera, and some who didn't).
The orginal 1.0 ELF specification came primarily out of work by engineers at Intel. The 1.2 specification, which *did* have significant work done by USL, was done under the auspices of TIS, with the *explicit* understanding that the result would be available as an ABI standard for all.
ftp://ftp.digibd.com/ USA GMT -6 25-Jan-95 belal@sco.com (Bela Lubkin> {posting}
DigiBoard
keng@digibd.com
Server : http://www.digibd.com/
Files : Digiboard (digifax, digiline: drivers, isdn); pub: HP4laser (lp
model for autohandling of PCL/PostScript jobs), SCO-ports,
uiarchive (archive of the defunct Unix International effort),
unixware, WWW
Note that this is just an excerpt from a Usenet posting for the site listing for the site - the mirroring occurred in early 1994 (January, if I remember correctly), and the UI servers were defunct as of Mar 1994, when the mailing list archives were moved over. Novell acquired USL from AT&T in Jun 1994.
An ironic, IMO, thing to note in the posting above is that the location of the archive is being disseminated by an SCO (the real SCO) employee.
-- Terry
You've never heard of "The Grateful Dead"?
They permitted taping of their concerts and trading of the tapes since very nearly their first concert. See:
http://en.wikipedia.org/wiki/Grateful_Dead#Tapers
As long as the tapes weren't being used for commercial profit, it was effectively a free-for-all, to the point of them setting up a "taper's area" to allow their own sound crew to have access to the area where they'd need to set up their equipment for the best sound for the concert.
There were/are a number of other bands that had/have the same practice: Rat Dog, The Other Ones, etc..
-- Terry
It would kill *ALL* general purpose comnputing.
The only safe language to code in would be assembly, and you'd have to write all the code yourself, unless you wanted to be liable for the output of the compiler or the libraries you linked to.
Shared libraries and loadable modules couldn't be trusted, since if your application had them, someone else could substitute a different library or module, and your code would never know the difference. If you added checking mechanisms to *for sure* know the difference yourself, you'd have to trust the FS.
All applications would have to be embedded applications, since you couldn't trust an OS vendor - what would happen if the system call behaviour was changed by the OS vendor? What if it wasn't by the OS vendor - what if the OS vendor trusted third party companies to write drivers?
What about firmware? The OS trust the firmware to load it! What if the firmware changes, or isn't exactly the firmware you expected?
What about the hardware? What if the instruction set on the CPU changes? You'd have to tie your software to particular hardware; historically, for example, 6502 processors were mask-programmed, and had "in between" op codes - they'd do something, but what the side effects were depended on the chip stepping. Your code could work in testing, but not in production unless you guaranteed the same chip lot, since it might be working as a result of a serendipitous error that was fixed in the next chip.
Down this road, you'd only ever have software sold by people who made the OS sold by the people who wrote the firmware sold by people who built the hardware... and maybe the components of the hardware themselves.
So basically you'd have... what... nothing left, but IBM from the 1950's?
-- Terry
You are incorrect, sir.
/dev/null and /dev/zero, and then turn any reads or writes from either around immediately in the first function called out of the sysent[] table as soon as you see an fd pointing to one or the other, and never enter into the rest of the kernel. Then you can run the lmbench "system call speed" tests, with everything *but* the call site overhead factored out.
It is a trivial experiment to initially cache the vp for
The real problem here, though, is the perception that system call trap speed is actually somehow very important. This has grown out of the Linux community.
Part of it is Larry McVoy's benchmark suite, designed to make Linux look better than other OSs; the perception that system call speed is important is based on the idea that since it can be measured, making it small as possible is worthwhile. As evidendence that this is actually jingoistic, the previous "null system call" implementation in LMBench was actually getppid(), and prior to that, it was getpid() (the result of getpid() is cacheable in user space in Libc). As other OSs have started turning the calls around faster, other calls have been selected to keep Linux ahead.
The second part of the problem is deeper, and goes to how people program software being influenced by their execution environment, and their perception. This is more problematic. Whether it's the idea that it's OK to not bzero() a sockaddr_in before using it in a call to connect() (which works on Linux, but fails on most BSD derived systems because of the "mutual connect" case in the TCP state machine that isn't accounted for in the Linux implementation), or it's the idea that thread creation or system calls are "free", and therefore not to be avoided, or whether its something else, it ends in bad code.
My canonical example for this is MySQL's client libraries, which end up making multple system calls (3 of them) per transaction, when they could get by with a single system call simply by buffering their data per client connection, rather than per thread in the MySQL server. This simple change would amount to a huge performance improvement on most OSs; Linux itself would see perhaps a 5% performance improvement from the change. But it would be an improvement. Yet people keep pointing to MySQL as a benchmark, when what they are measuring is actually a design problem in the database, not the OS on which it's running.
The problem is that most people don't change code, once they get it to the point that it works well enough for their initial uses - and short of someone doing a deeper port than just a trivial "get it compiling and running" type port, you're not going to see the performance on *any* platform that wasn't the initial platform where the code was written and tuned. Or to put it another way, the person most capable of tuning the code is almost never going to be the person moving it to a new platform; so platform assumptions built into the implementation of the code - or worse, the design of the code - are going to bite everyone that moves it to a new platform.
For thread creation - well, you know, there's a good reason that Apache pre-spwans anonymous workers, and applications that don't are probably assuming that thread or process creation is "free" or close enough that they don't care.
Personally, I'm not that impresed with benchmarks that purport to measure kernel performance; other than I/O, where most of the time is spent waiting on whatever you're talking to, well written applications tend to spend their time in user space; I've heard that on MacOS X, it's usually more than 80% of the time in user space, and for multimedia or compute bound applications, it can get a lot higher than that.
Microbenchmarks have their place; they are useful for comparing against yourself, and for detecting regressions before they become entrenched. But they aren't very useful for anything else, and exspecially not for comparing one OS to another.
-- Terry
Mac Intel laptops can boot from USB
You just need to:
(1) Have a bootable USB drive plugged in
(2) Hold down the option key while powering on
The drive will show up as one of the allowed boot devices in the boot picker.
-- Terry
I doubt it.
Most laptops are seriously limited by form factor of the particular cards it's expected to accept in such a slot - in general, they are not full sized cards, but as small as they can make them, and potentially oddly shaped, if they are on an internal connector.
The other limitation that a card could throw way off kilter - particularly, a display card replacement - is the thermal budget. You're already seeing vendors selling laptops that *must* have power management to enable them to run within their thermal budget when the ambient temperature is higher than some minimum below which there is no throttling required (say 60 degrees Fahrenheit).
Putting in a very large, high thermal output graphics card, even if it would fit (see first paragraph) will at best blow your thermal budget; at worst, the heat pipes for the card, even if they happened to hput the hot spots in the same place, would be unlikely to be able to dissipate the load - either because they are undersize, or because they share their heat sinks with other components that are already pushing them at their effective limits.
So I seriously doubt you are going to have a lot of component upgradeable laptops available. There might be one or two niche vendors that over-engineer their thermal envelopes so they can handle upgrades, but... expect them to be much heavier in general, for the "generic" heat piping and sinking, and to potentially be noisier, if they also end up with higher air flow fans to cool above the expected default configuration load.
I don't think the "Road Warrior" market is big enough to support someone like a Dell or an Apple building and marketing one of these monsters.
-- Terry
Can we get this article retitled?
Maybe something like "Henry Python and the blog of shame"?
-- Terry
KSE was not implemented to design
When I first proposed KSE, my proposal was that all system calls become asynchronous - you dispatch the system call. Then, if you wanted POSIX semantics, you suspended yourself until the result was available.
The intent was to implement all of the POSIX blocking semantics at the Libc layer, and all the operational semantics at the kernel layer, and to permit any number of dispatches to occur concurrently.
The way you implement multithreading in this environment is to use call-conversion scheduling: you trade a normally blocking system call for a non-blocking system call plus a context switch. This basically gets you multithreading for free.
The intent of this approach is to utilize your full process quantum, rather than giving it away and suffering an unnecessary context switch overhead, while you still had work pending that could be done in user space within the same process.
In one posting, I put it like this: "If a kernel gives me a quantum, it's *my* damn quantum, and I'll use as much of it as I can, and if I can't use any more,*then* I will yield to a voluntary context switch".
The way you obtain SMP scalability (which was *NOT* the original reason threads were invented in the first place, BTW, since they predated commercially viable SMP system by a long ways) is by permitting multiple processors to return to user space on completed async system calls.
Intelligent readers will not that by not giving away the quantum you were given, you basically get a form of CPU affinity thrown in for free, without any modification to the kernel scheduler, up to the point where you would context switch to a process other than yourself, and cache-bust/TLB-shootdown anyway. This was not a bad idea.
-
What happened instead was an implementation of SA (Scheduler Activations). They kept the KSE name. I came up with it initially - "Kernel Schedulable Entitites" - because I didn't want people to be thinking about solving the problems we intended to solve in a way that was constrained by the ideas that would carry over from using words like "activations" or "threads" or whatever. Semantic loading constrains free thought on technical issues a heck of a lot more than people give it credit for.
But SAs fell far short of my intended vision for the original implementation, a vision I could not implement on my own without buy in from the rest of the FreeBSD community.
-
Once we got buy-in that we were going to do *something* in this area, we had a big meeting. It was hosted at Whistle Communications, where Julian and I and others worked, and where we tended to host BAFUG meetings. Jason Evans and others attended.
I was unfortunately unable to sell my async call gate approach to the problem ("too many changes"), and a compromise was worked on scheduler activations, and a user space thread scheduler that would cooperate with the kernel scheduler.
Compared to what we ended up with, the changes required for the async call gates would have been a lot less code. But I fully admit: my suggested approach would have been impossible to implement incrementally - it would have been all or nothing, and stepping over that threshold would have cost a lot. I failed to sell it adequately, and can only fault myself.
-
Realize that this was not a bad compromise, given the technology at the time: context switches were murder, and crossing the user/kernel protection domain was a heck of a lot more expensive than it is on todays hardware. Also, the vast majority of SMP Intel boxes available in 1996/1997 were at best 2 processor boxes (I still have my dual P90 ASUS box).
Later, the expense of scheduler activations became plain, but it was still not too bad, until things like TLS - "Thread Local Storage" - and other POSIX semantics changes started to make things more painful.
-
Meanwhile, FreeBSD got thread reentrancy work done in its kernel, and a separation of address spaces and contexts, that it would have needed to have, no matter what threading approach was used. So KSE's, even implements as the were, instead of how I had originally envisioned them, was well worth it.
-- Terry
There is a huge amount of mainstream coverage of this.
h tm, which permits the corporations to *voluntarily* disclose these records to anyone they want, including the estranged husbands of battered women, if it suits them.
NB: I listen to both liberal and conservative radio talk shows on and off, and touch base with both liberal and conservative press when I have the time to do so. In the interestes of full disclosure, I'm pretty jaded about our media.
In general, the liberal portions of the press are formally outraged, but are conveniently ignoring Title 18 USC 2701 (c)(1) http://www.usdoj.gov/criminal/cybercrime/usc2701.
While the conservative portions of the media are protesting that the operations are perfectly legal, but not pointing to this as a voluntary disclosure (the companies involved were in fact paid $$$ to "volunteer" the records), and are themselves ignoring the fourth ammendment issues and the common law privacy rights issues surrounding the constitutionality of Title 18 USC 2701 (c)(1) in the first place.
Meanwhile, everyone is ignoring the fact that there are two sets of surveillance operations: one, which broke in the news months ago, having to do with actual communications intercepts, and this more recent one, which has to do with collection of information for traffic analysis (and from that, subsequent social network analysis built on top of that).
The liberal side is trying to paint this traffic analysis as if the "communications records" in question were actual recordings of conversations, rather than endpoint identification and call duration; the conservative side is still defending everything as being perfectly legal and above board (techincally, they are correct about the legality, from my reading of the laws, but whether or not this is "above board" really relies on whether the laws being used to collect the information are in fact constitutional).
Nobody is addressing whether or not the Patriot Act provisions mean this same information can be used by law enforcement for non-terrorist related criminal investigations, or what the implications are for tarring people with the same brush, if they happen to have a black sheep in their family who keeps in touch, and therefore associates them with a legitimately identified criminal social network.
I also haven't heard anyone talking about whether or not standard traffic analysis fuzzing techniques are being utilized by The Bad Guys(tm), like intentionally identifying phone numbers associated with groups, and calling them from within multiple points in a covert terrorist network, to link the networks together, and therefore either (a) hide in plain sight, or (b) broaden the target list sufficiently that the investigative requirements would be prohibitive. All it would take is different people calling from the same phone number to the same network connection point with a "wrong number" and being excessively chatty to get the connection time up.
Nobody in the media is talking about what happens when these records, if they are shared, are mined after the fact to provide overwhelming circumstantial evidence in the pursuit of a personal vendetta against a private citizen by a minor official.
All in all, it's a standard media feeding-frenzy, with a lot of noise, no one touching any of the important issues (might kill the goose that laid the golden egg, doing that...), and both sides posturing in no provable or disprovable way that might end up stopping the fun before the subject has been milked for all the public attention that they can wring out of it.
Hope that answers your question.
FWIW: I think my cynicism here is fairly representative of most average "man on the street" U.S. Citizens. Don't take the actions of our government, or the distorted cartoons of those actions, as represented by our media, at face value, and don't take them as being representative of U.S. Citizens in general; we aren't the jackasses our media makes us out to be.
-- Terry
Wile E. Coyote ... Suuuuuuperrrr Geeeeniusssss!
-- Terry