That's ViRGE, "Video and Rendering Graphics Engine". I had one, and I recall that on the MS flight-sim of the day, software rendering was actually faster, although only by a couple of percentage points.
Actually, you don't. All you need is for the muon to live long enough for the fusion to take place. And, as it happens, muons live long enough to catalyze many fusion events.
Muon-catalyzed fusion is a well-studied problem, and one on which I did a graduate term project many years ago. The big problem isn't the muon lifetime -- everything works pretty well, you can get the muons to replace electrons in singly-ionized D-D or D-T molecules, and they even ratchet themselves down to the lowest-energy muonic states quite quickly, and after that, the fusion happens more than fast enough. When I did my project, the big problem was with muon recycling -- once the fusion event occurs, the muon might be ejected, or it might be bound to the He fusion product for the high-energy D-T case.
Binding to the He (called "alpha-sticking" in the jargon) is very bad, it makes the muon unavailable to catalyze more reactions, no matter how long the damn thing lives. As of about 1993, the state of the art was, you needed to use D-T fusion to have any hope of achieving energetic break-even, but D-T fusion was plagued by alpha-sticking, so break-even wasn't happening.
A longer-lived muon would help, obviously, since they're energetically expensive to produce, but the muon lifetime is far from the limiting factor in this process.
The existing Soyuz TMA capsules also have "soft-landing rockets", they're used just at the point of touchdown to cushion the landing. Of course, the TMAs also have a parachute, so it's less of a problem if the landing rockets fail. Interestingly, the very first Soyuz TMA had all kinds of other problems, but the landing-rocket part actually worked.
> Just go into whatever driver code that handles the MTRR/proc filesystem and have it spoof writes. The invading rootkit will think "all is swell", and it won't be.
Indeed. In particular, this exploit is really only scary-bad on virtual servers, since it might allow someone with root on a virtual system to get root on the physical box. (On any other system, the attacker was already root, so it's a matter of closing the barn doors...)
A sensible-seeming precaution would be to just disable/proc/mtrr in particular on virtual servers -- it refers to a global physical register, and that's out of scope for a virtual machine anyways.
In Linux, the/proc pseudo-filesystem exposes the kernel internals. Anyone can read/proc/mtrr, and root can write it. It's one line of bash, and zero lines of assembler. No idea how to do it on Windows.
Submitter here -- Kelso's Corner was where I first saw it, so I felt some credit was due. They also had the broader link to more content about public art on Google StreetView, so I felt they added a bit of value. I figured if that sort of thing was a problem, our dutiful and diligent Slashdot editors would edit it appropriately.
For the record, I have no affiliation of any kind with Kelso's Corner, the Washington Post, or Google.
Not sure if you need to do this to get it, but if you get the "Blade Runner Five-disk Ultimate Collector's Edition" (yes, that's really what it's called, and yes, I have it), it includes the original US theatrical release, with the voice-over.
I was never sure about the voice-over, myself. I saw that version first, in theatres, back in the day, and I thought the voice-over was annoying, a bit too "Magnum P.I.", clubbing me with context. When I saw the "director's cut" later on, I liked it better, but of course, I had already seen the first one, so I knew the context. It's easy to imagine that if you see the "director's cut" first, it'd be pretty confusing.
I do think there needs to be less voice-over, particularly towards the end. By that time, the context is established, and the awesome visuals really do work better on their own.
I use cvs, and frequently have several files in emacs buffers when I do a commit. CVS modifies the buffers to put new time-stamps in them, and it used to be, every time I edit a buffer, I get one of these "File modified on disk, really edit? Revert?" things.
So, I wrote my own "revert-all-buffers" command.
Mangled to get through the Slashdot lameness filter.
Clumsy wording, sorry. I meant potentially exposed to other users *through* the OS. Other users can find your file or named pipe and DOS your process by deleting it, if you're not careful with permissions etc., but such an attack is much harder against intra-process, inter-thread shared memory.
Having gotten several gray hairs from debugging thread-lock issues, I can't help but wonder how these processes do IPC. Presumably complex objects (in the OOP sense) have to be serialized and written to files or piped through sockets. That's not necessarily a bad idea, but it means the data pathways are exposed to the OS, and it's a potential security issue, too.
> Unions don't make any industry more efficient, and that loss of efficiency can mean the difference between a successful company and an unsuccessful company.
Gonna burn some karma here...
In fairness, efficiency is not the goal of unions. The theory is that the collective bargaining means the workers can get a better deal for themselves, because they're in a stronger negotiating position as a group than any of them is individually. Of course the company will be less efficient.
Protecting people is always inefficient. The leading example in this topic was about electrical codes, and I think it was interesting that the virtue of electrical codes was assumed in that discussion right alongside the demonization of unions.
But if we really value efficiency, shouldn't we dispense with electrical codes? Real electrical experts will use their knowledge to wire things safely, and people who do dangerous work will be weeded out by their bad reputation, and everything will work better and cost less, right?
Enforcing electrical codes compromises efficiency in the name of safety, so people's lives are protected.
Collective bargaining asks for a similar trade-off, compromising efficiency in order to better protect worker's livelihoods and worker investments in their careers.
That isn't to say that an IT union is necessarily a good idea or a bad idea. I'm just trying to get across the radical idea that "it reduces efficiency", concentrating on the cost and ignoring the benefit, isn't a compelling, or even sufficient, argument.
They probably had a no-bid phone contract from KBR shoved down their throats over at DHS. And since DHS workers aren't in the civil-service union, there's no whistleblower protection, so nobody squawked.
Many, many users have the problem that the first writer had, namely, they have no idea where the "internal boundaries" are between various entities available on their computer. From their point of view, the modern GUI desktop is an undifferentiated sea of icons and buttons and text boxes. Users know what sequences to use to achieve a desired effect, but as far as how it works or even what the components are, or which ones are local and which ones are remote, they may not know, and the interface doesn't always tell them. I recently had this experience doing tech-support for my father, who was visiting me. His e-mail stopped working, because his local POP/SMTP mail client will only talk to his ISP's servers when connecting from within the ISP's domain. At home, he's on the ISP's cable modem, and it works. I have a different ISP, so it doesn't work at my house. I switched him to the web client, which he was able to adapt to, but I'm not sure he ever really understood why he had to do that. I can easily imagine that the guy in the first example normally had his browser default to open to his ISP's portal page, and it might have even had an e-mail link that send messages to the ISP's support team. So he goes to another computer and does what he thinks is the same thing -- opens a browser, fusses with it until a page comes up with something that looks like an e-mail link, clicks on it and asks for help. He's at the library, maybe some joker has set the default home page to slashdot, maybe it autocompleted it out of the history, who knows. Ignorant, yes. Stupid? Only if it persists...
The Fourth Amendment provides for security in persons, papers, effects and so forth from the government. Even if you construe it to be a privacy provision, it's not binding on Joe Sleazeball's Krazy Komputer Krepair Kshop.
I believe you're right, for normal values of "widely distributed", but I am aware of a promising candidate. Cacert.org provides free authority certificates, and their root certificates are bundled with Debian, and some other Linux distros. If the Firefox guys got on board, this could work.
Your city must be in Europe, possibly eastern Europe. In most US mass transit systems, fares are at least a dollar each way. Ten bucks a week is 1% of a $52,000 annual gross income, which is certainly in the middle-class ballpark, though on the low side for a technology professional.
I personally live in a dense east-coast US metropolis that happens to have the most expensive mass transit in the US, and found a good job that happens to be in the burbs. I can spend almost ten bucks a *day* if I commute by subway. It does keep the *gas* expenditures down to do that, so I guess I can compete with all the other urbanites on that score.
That's ViRGE, "Video and Rendering Graphics Engine". I had one, and I recall that on the MS flight-sim of the day, software rendering was actually faster, although only by a couple of percentage points.
> You need a stable muon first.
Actually, you don't. All you need is for the muon to live long enough for the fusion to take place. And, as it happens, muons live long enough to catalyze many fusion events.
Muon-catalyzed fusion is a well-studied problem, and one on which I did a graduate term project many years ago. The big problem isn't the muon lifetime -- everything works pretty well, you can get the muons to replace electrons in singly-ionized D-D or D-T molecules, and they even ratchet themselves down to the lowest-energy muonic states quite quickly, and after that, the fusion happens more than fast enough. When I did my project, the big problem was with muon recycling -- once the fusion event occurs, the muon might be ejected, or it might be bound to the He fusion product for the high-energy D-T case.
Binding to the He (called "alpha-sticking" in the jargon) is very bad, it makes the muon unavailable to catalyze more reactions, no matter how long the damn thing lives. As of about 1993, the state of the art was, you needed to use D-T fusion to have any hope of achieving energetic break-even, but D-T fusion was plagued by alpha-sticking, so break-even wasn't happening.
A longer-lived muon would help, obviously, since they're energetically expensive to produce, but the muon lifetime is far from the limiting factor in this process.
The existing Soyuz TMA capsules also have "soft-landing rockets", they're used just at the point of touchdown to cushion the landing. Of course, the TMAs also have a parachute, so it's less of a problem if the landing rockets fail.
Interestingly, the very first Soyuz TMA had all kinds of other problems, but the landing-rocket part actually worked.
> Just go into whatever driver code that handles the MTRR /proc filesystem and have it spoof writes. The invading rootkit will think "all is swell", and it won't be.
Indeed. In particular, this exploit is really only scary-bad on virtual servers, since it might allow someone with root on a virtual system to get root on the physical box. (On any other system, the attacker was already root, so it's a matter of closing the barn doors...)
A sensible-seeming precaution would be to just disable /proc/mtrr in particular on virtual servers -- it refers to a global physical register, and that's out of scope for a virtual machine anyways.
In Linux, the /proc pseudo-filesystem exposes the kernel internals. Anyone can read /proc/mtrr, and root can write it. It's one line of bash, and zero lines of assembler.
No idea how to do it on Windows.
Works on Debian, of course. Maybe Ubuntu, too.
> Yes, Mages are known for powdering their cheekbones. Rogue's on the other hand, like to stab people in the back.
So whose law is it that spelling/grammar corrections have grammer errors? Or are you just trying to twit the pedants with your rouge apostrophe there?
Submitter here -- Kelso's Corner was where I first saw it, so I felt some credit was due. They also had the broader link to more content about public art on Google StreetView, so I felt they added a bit of value. I figured if that sort of thing was a problem, our dutiful and diligent Slashdot editors would edit it appropriately.
For the record, I have no affiliation of any kind with Kelso's Corner, the Washington Post, or Google.
Not sure if you need to do this to get it, but if you get the "Blade Runner Five-disk Ultimate Collector's Edition" (yes, that's really what it's called, and yes, I have it), it includes the original US theatrical release, with the voice-over.
I was never sure about the voice-over, myself. I saw that version first, in theatres, back in the day, and I thought the voice-over was annoying, a bit too "Magnum P.I.", clubbing me with context. When I saw the "director's cut" later on, I liked it better, but of course, I had already seen the first one, so I knew the context. It's easy to imagine that if you see the "director's cut" first, it'd be pretty confusing.
I do think there needs to be less voice-over, particularly towards the end. By that time, the context is established, and the awesome visuals really do work better on their own.
IMHO, obviously.
> Gmail has supported forwarding mail and exporting contacts for as long as I can remember.
Really? You might see a doctor about that. I can actually remember a time when there was no Gmail at all -- it wasn't *that* long ago.
I use cvs, and frequently have several files in emacs buffers when I do a commit. CVS modifies the buffers to put new time-stamps in them, and it used to be, every time I edit a buffer, I get one of these "File modified on disk, really edit? Revert?" things.
So, I wrote my own "revert-all-buffers" command.
Mangled to get through the Slashdot lameness filter.
(defun revert-all-buffers () (interactive) (let ((bufcount 0)) (save-current-buffer
(mapc (lambda (buf) (if (buffer-file-name buf)
(if (verify-visited-file-modtime buf) nil
(progn (set-buffer buf) (revert-buffer t t) (setq bufcount (1+ bufcount))
)) nil )) (buffer-list) ) )
(message "Buffers reverted: %d" bufcount)))
But then you'll lose these!
Say it ain't so...
YM std::cerr << "Hello World" << std::endl;
HTH.
C++, which is more abortionate, not equal. Plus I was retrofitting threading into existing software. I got better.
Clumsy wording, sorry. I meant potentially exposed to other users *through* the OS. Other users can find your file or named pipe and DOS your process by deleting it, if you're not careful with permissions etc., but such an attack is much harder against intra-process, inter-thread shared memory.
Having gotten several gray hairs from debugging thread-lock issues, I can't help but wonder how these processes do IPC. Presumably complex objects (in the OOP sense) have to be serialized and written to files or piped through sockets. That's not necessarily a bad idea, but it means the data pathways are exposed to the OS, and it's a potential security issue, too.
> Who gives a flying fuck if they watch you do mundane crap that nobody will care about anyway?
Me. Because today's mundane crap is tomorrow's suspicious behavior. Because information in the aggregate is more than the sum of the parts.
Also, I note that you are posting anonymously. What do you have to hide? Hmm?
> Unions don't make any industry more efficient, and that loss of efficiency can mean the difference between a successful company and an unsuccessful company.
Gonna burn some karma here...
In fairness, efficiency is not the goal of unions. The theory is that the collective bargaining means the workers can get a better deal for themselves, because they're in a stronger negotiating position as a group than any of them is individually. Of course the company will be less efficient.
Protecting people is always inefficient. The leading example in this topic was about electrical codes, and I think it was interesting that the virtue of electrical codes was assumed in that discussion right alongside the demonization of unions.
But if we really value efficiency, shouldn't we dispense with electrical codes? Real electrical experts will use their knowledge to wire things safely, and people who do dangerous work will be weeded out by their bad reputation, and everything will work better and cost less, right?
Enforcing electrical codes compromises efficiency in the name of safety, so people's lives are protected.
Collective bargaining asks for a similar trade-off, compromising efficiency in order to better protect worker's livelihoods and worker investments in their careers.
That isn't to say that an IT union is necessarily a good idea or a bad idea. I'm just trying to get across the radical idea that "it reduces efficiency", concentrating on the cost and ignoring the benefit, isn't a compelling, or even sufficient, argument.
Um, GNU/Linux replaces OS-X?
Oops, knee jerked a little too fast. FEMA, dammit, not DHS. I hate it when screw-ups don't ratify my world-view.
They probably had a no-bid phone contract from KBR shoved down their throats over at DHS. And since DHS workers aren't in the civil-service union, there's no whistleblower protection, so nobody squawked.
Many, many users have the problem that the first writer had, namely, they have no idea where the "internal boundaries" are between various entities available on their computer. From their point of view, the modern GUI desktop is an undifferentiated sea of icons and buttons and text boxes. Users know what sequences to use to achieve a desired effect, but as far as how it works or even what the components are, or which ones are local and which ones are remote, they may not know, and the interface doesn't always tell them.
I recently had this experience doing tech-support for my father, who was visiting me. His e-mail stopped working, because his local POP/SMTP mail client will only talk to his ISP's servers when connecting from within the ISP's domain. At home, he's on the ISP's cable modem, and it works. I have a different ISP, so it doesn't work at my house. I switched him to the web client, which he was able to adapt to, but I'm not sure he ever really understood why he had to do that.
I can easily imagine that the guy in the first example normally had his browser default to open to his ISP's portal page, and it might have even had an e-mail link that send messages to the ISP's support team. So he goes to another computer and does what he thinks is the same thing -- opens a browser, fusses with it until a page comes up with something that looks like an e-mail link, clicks on it and asks for help. He's at the library, maybe some joker has set the default home page to slashdot, maybe it autocompleted it out of the history, who knows.
Ignorant, yes. Stupid? Only if it persists...
The Fourth Amendment provides for security in persons, papers, effects and so forth from the government. Even if you construe it to be a privacy provision, it's not binding on Joe Sleazeball's Krazy Komputer Krepair Kshop.
> AFAIK, anyway.
I believe you're right, for normal values of "widely distributed", but I am aware of a promising candidate. Cacert.org provides free authority certificates, and their root certificates are bundled with Debian, and some other Linux distros. If the Firefox guys got on board, this could work.
Your city must be in Europe, possibly eastern Europe. In most US mass transit systems, fares are at least a dollar each way. Ten bucks a week is 1% of a $52,000 annual gross income, which is certainly in the middle-class ballpark, though on the low side for a technology professional.
I personally live in a dense east-coast US metropolis that happens to have the most expensive mass transit in the US, and found a good job that happens to be in the burbs. I can spend almost ten bucks a *day* if I commute by subway. It does keep the *gas* expenditures down to do that, so I guess I can compete with all the other urbanites on that score.
Exercise for the reader: Name that metropolis!