Most people agree Roland "Fuckeyfacey" Piquepaille's Technology Trends is a bullshit website.
Yet we keep seeing it linked from Slashdot.
I wouldn't mind if someone stole the content of Roland's article, removed the bullshit, added some more informative links, and then pretended to have stumbled across whatever it was, and posted it to Slashdot.
But I wish they would stop accepting submissions from him. He is just shitting all over slashdot for referral ad money.
Jesus, what's wrong with 32 (RGB-10bit)?? 1024 discrete levels is about as good as your ever going to get on a CRT or LCD with the contrast ratios available to you. Studios use 16-bit per channel, but that's mostly because they have lots of inbetween processing stages and the projectors can potentially have a much higher dynamic range. That is, so dark parts can be very dark, and light parts can be very light without saturation... And still that's only 48-bits. So where do you get 64? RGBA*2? I'd at least drop that alpha part in the backend of the renderer/frontend to the DAC, as it could only slow things down.
Rather, they use OpenGL and a thin API over the other parts of DirectX (sound, input). OpenGL is cross-platform.
Porting is not bad... 1) Most resources are relative paths inside zip files or flat in a directory, so you remove filesystem issues (path seperators/case sensitivity). 2) The game code that uses DirectX for non-video stuff is kept to a library used specifically to interface the game code to the system. Most of the work is just rewriting that library to use equivalent functions on Linux. 3) WineX has a DirectX emulation layer that can be used as a guide for 3. 4) Side note- SDL pretty much takes care of everything in DirectX, minus DirectShow. Can also be used as a guide. 5) NVidia has development tools (shader compilers and whatnot) that work on Linux.
It's probably not a Microsoft problem if the system is running on NT, it uses a 64-bit time.
It _could_ be that an important part of the system is running Windows 95 interfaced to a 2k domain that implements the rest of the system. That really isn't Microsoft's fault that they didn't patch that critical machine to fix the flaw... or that they felt they needed to run Windows 95 (gag) in such a critical portion of the system.
It _could_ be that a user-land air traffic control related application itself calls an depricated API to return the time in microseconds, which overflows/wraps around, causing the software to crash. OR It _could_ be that the user-land air traffic control software just mis-casts the time from the modern API into a 32-bit data structure, which wraps around, causing the software to crash. In the latter two cases the article writer or LAX's press staff may have incorrectly drawn the connection to the famous Windows 95 problem... even when it wasn't Microsoft's fault in that case.
I really don't see how Microsoft could be the blame here at all...
On some systems (Solaris specifically) the linux-weened will quickly learn that reboot or halt is NOT the command they wanted to run...
Actually the linux-derived programs reboot, halt and poweroff do exactly that but they first check the runlevel... if reboot detects the runlevel is not 6 or s it will call shutdown to tell init to enter runlevel 6. If halt/poweroff detects the runlevel is not s or 0 it will call shutdown tell init to enter runlevel 0. They are designed to do double duty... to be called at the end of rc.d scripts and for super-user usage. You can force them to immediately shutdown or reboot without checking the runlevel by using the -f option.
Of course, the SunOS supplied binaries do not have this safety check... I'd recommend against getting used to that. Just pass the appropriate option to shutdown... (-r for reboot, -p for poweroff, halt is the default)
Get a phone with Java. Make sure your home machine is using NTP (or GPS, or both) to keep accurate time. Your phone should get it's time from the cell tower (or GPS if it has that).
Write a J2ME app (or find one, I think you can) that takes the current time rounded to the nearest minute, asks you for an unlocking-PIN, which is used to decrypt a shared secret. Hash the secret with the current time (SHA-1 is good enough). Show the lower 8-bytes or something.
On the server, write a PAM module that does the same thing, except maybe it creates 8-byte hashes for a minute behind and ahead and behind too, and accepts any of them (to account for time jitter).
So you go to log in, pop open your java app on your cell, type in the PIN, write down the hash, and then use that to login via SSH or FTP or whatever.
Of course, ssh public-key authentication is just as secure as this (you have key halves on each side, the client side's protected by a pass-phrase, you encrypt a random challenge which is dependant on time, among other things...) Actually, I think I trust a PKI-scheme with 1024+ bits more than a symmetric hash-based system.
I'm sure they wouldn't object to contributing any patches to firefox if they made some changes... But if it's mostly changes to the chrome, they don't have to make it open source. The can just leave it in the jar files and let interpid users try to peel apart the XUL and stylesheets and whatnot to see how it's implemented.
There is much to be said about changes in how the world worked between the 16 and 17th centuries. Stephenson tries to capture many aspects and solidify in a narrative form. The changes in finance are particularly interesting (see also Cryptonomicon...) so they pretty much occupy the whole second book.
It got me really interested in my economics classes...
that have nothing to do with the implementing programming language.
Remember the URL path hacks, esp. on Macs? foobar:/local/path links combined with location.href redirecting javascript... no buffer overflows there.
Many of the old outlook flaws that propogated some huge viruses and worms were because of how shittily it handled MIME-types and what attachments should be activated in the preview pane...
Again.
Sometimes the biggest problems aren't the much maligned buffer overflows but by people figuring out using features of software in ways that it was not intended.
if you look, he didn't post one picture per day to cover the 35 pictures per day already up... There were a bunch of stuff in the beginning of august flirting with doing just a top ten, with a few pictures unnumbered... and it jumps from sept 9 to august 30.
So maybe the person got the idea to make it an april fools day joke after already starting the blog?
It all depends on the colors on the clothing of the actors whether they do a blue or green screen for a particular scene. It also may depend on the lighting they are trying to use (need to add directional color the actors, but not effect the hue of the screen in the shot)
Portland Compiler Group has a compiler that's fairly decent and optimizes for both AMD64 and Intel 32-bit (although they're pushing the AMD64/clustering angle right now).
It's nice, but much less free. 15-day free trial. Prices are not bad, but it's still a little steep, even for an academic license.
This is not a plug... just in case anyone was wondering if there was something besides ICC you could try in to benchmark GCC on something that ICC can't cope with.
to do it use a very large RAM disk loaded from the flash, which you then either batch copy into the flash FS at intervals, or at shutdown. (The latter is more likely as DRAM is as cheap or cheaper than Compact Flash capacity-wise).
Hence the flash is really only there to help it between power cycles, or to "back" in-flight data.
I could probably find one... but there should be a flash/RAM fs that does mostly everything in memory with an update-to-backing-flash-at-interval feature. Or you could somehow tune the buffer cache to be _really_ lazy about when it gets around to writing, and only to write in huge sequential blocks.
Slashdot Mirror
Most people agree Roland "Fuckeyfacey" Piquepaille's Technology Trends is a bullshit website.
Yet we keep seeing it linked from Slashdot.
I wouldn't mind if someone stole the content of Roland's article, removed the bullshit, added some more informative links, and then pretended to have stumbled across whatever it was, and posted it to Slashdot.
But I wish they would stop accepting submissions from him. He is just shitting all over slashdot for referral ad money.
Jesus, what's wrong with 32 (RGB-10bit)??
1024 discrete levels is about as good as your ever going to get on a CRT or LCD with the contrast ratios available to you.
Studios use 16-bit per channel, but that's mostly because they have lots of inbetween processing stages and the projectors can potentially have a much higher dynamic range.
That is, so dark parts can be very dark, and light parts can be very light without saturation...
And still that's only 48-bits. So where do you get 64? RGBA*2?
I'd at least drop that alpha part in the backend of the renderer/frontend to the DAC, as it could only slow things down.
Step 2) laugh and don't use it anyway
Step 3) don't be an ass pirate, leave bittorrent running.
^_^
Rather, they use OpenGL and a thin API over the other parts of DirectX (sound, input). OpenGL is cross-platform.
Porting is not bad...
1) Most resources are relative paths inside zip files or flat in a directory, so you remove filesystem issues (path seperators/case sensitivity).
2) The game code that uses DirectX for non-video stuff is kept to a library used specifically to interface the game code to the system.
Most of the work is just rewriting that library to use equivalent functions on Linux.
3) WineX has a DirectX emulation layer that can be used as a guide for 3.
4) Side note- SDL pretty much takes care of everything in DirectX, minus DirectShow. Can also be used as a guide.
5) NVidia has development tools (shader compilers and whatnot) that work on Linux.
Same goes for MacOSX, really...
Whoever designed it gets a gold star.
Play this into your phone...
...but they couldn't script it to do an orderly shutdown? I mean what does the technician do differently that it doesn't interrupt air traffic?
Right?
I mean, why bother writing a timed script if it doesn't have a failsafe?
Don't tell anyone...
lol CAASD@MITRE ownzors j00
It's probably not a Microsoft problem if the system is running on NT, it uses a 64-bit time.
It _could_ be that an important part of the system is running Windows 95 interfaced to a 2k domain that implements the rest of the system.
That really isn't Microsoft's fault that they didn't patch that critical machine to fix the flaw... or that they felt they needed to run Windows 95 (gag) in such a critical portion of the system.
It _could_ be that a user-land air traffic control related application itself calls an depricated API to return the time in microseconds, which
overflows/wraps around, causing the software to crash.
OR
It _could_ be that the user-land air traffic control software just mis-casts the time from the modern API into a 32-bit data structure, which wraps around, causing the software to crash.
In the latter two cases the article writer or LAX's press staff may have incorrectly drawn the connection to the famous Windows 95 problem... even when it wasn't Microsoft's fault in that case.
I really don't see how Microsoft could be the blame here at all...
On some systems (Solaris specifically) the linux-weened will quickly learn that reboot or halt is NOT the command they wanted to run...
Actually the linux-derived programs reboot, halt and poweroff do exactly that but they first check the runlevel... if reboot detects the runlevel is not 6 or s it will call shutdown to tell init to enter runlevel 6. If halt/poweroff detects the runlevel is not s or 0 it will call shutdown tell init to enter runlevel 0. They are designed to do double duty... to be called at the end of rc.d scripts and for super-user usage.
You can force them to immediately shutdown or reboot without checking the runlevel by using the -f option.
Of course, the SunOS supplied binaries do not have this safety check... I'd recommend against getting used to that. Just pass the appropriate option to shutdown... (-r for reboot, -p for poweroff, halt is the default)
If you live there, you work there, not play there. You wouldn't pay as much taxes, etc. etc.
Of course, if it were only like that in real life...
Get a phone with Java. Make sure your home machine is using NTP (or GPS, or both) to keep accurate time. Your phone should get it's time from the cell tower (or GPS if it has that).
Write a J2ME app (or find one, I think you can) that takes the current time rounded to the nearest minute, asks you for an unlocking-PIN, which is used to decrypt a shared secret. Hash the secret with the current time (SHA-1 is good enough). Show the lower 8-bytes or something.
On the server, write a PAM module that does the same thing, except maybe it creates 8-byte hashes for a minute behind and ahead and behind too, and accepts any of them (to account for time jitter).
So you go to log in, pop open your java app on your cell, type in the PIN, write down the hash, and then use that to login via SSH or FTP or whatever.
Of course, ssh public-key authentication is just as secure as this (you have key halves on each side, the client side's protected by a pass-phrase, you encrypt a random challenge which is dependant on time, among other things...) Actually, I think I trust a PKI-scheme with 1024+ bits more than a symmetric hash-based system.
in a palm or something, using an access PIN to decrypt the local secret.
That only saves you money of course if everyone already has a PDA.
I'm sure they wouldn't object to contributing any patches to firefox if they made some changes...
But if it's mostly changes to the chrome, they don't have to make it open source.
The can just leave it in the jar files and let interpid users try to peel apart the XUL and stylesheets and whatnot to see how it's implemented.
But in order to do that, they have to have hooks into all the net-related applications you use (web-browser, email, instant messaging).
The huge search engine database mostly solves the problem of providing the meta-data for your data.
It makes sense to me.
There is much to be said about changes in how the world worked between the 16 and 17th centuries. Stephenson tries to capture many aspects and solidify in a narrative form. The changes in finance are particularly interesting (see also Cryptonomicon...) so they pretty much occupy the whole second book.
It got me really interested in my economics classes...
that have nothing to do with the implementing programming language.
Remember the URL path hacks, esp. on Macs? foobar:/local/path links combined with location.href redirecting javascript... no buffer overflows there.
Many of the old outlook flaws that propogated some huge viruses and worms were because of how shittily it handled MIME-types and what attachments should be activated in the preview pane...
Again.
Sometimes the biggest problems aren't the much maligned buffer overflows but by people figuring out using features of software in ways that it was not intended.
if you look, he didn't post one picture per day to cover the 35 pictures per day already up... There were a bunch of stuff in the beginning of august flirting with doing just a top ten, with a few pictures unnumbered... and it jumps from sept 9 to august 30.
So maybe the person got the idea to make it an april fools day joke after already starting the blog?
If not, then you should. It helps alot to use a "modern" linux font system that supports TTF, substitution and hinting and whatnot.
It all depends on the colors on the clothing of the actors whether they do a blue or green screen for a particular scene. It also may depend on the lighting they are trying to use (need to add directional color the actors, but not effect the hue of the screen in the shot)
Portland Compiler Group has a compiler that's fairly decent and optimizes for both AMD64 and Intel 32-bit (although they're pushing the AMD64/clustering angle right now).
It's nice, but much less free. 15-day free trial. Prices are not bad, but it's still a little steep, even for an academic license.
This is not a plug... just in case anyone was wondering if there was something besides ICC you could try in to benchmark GCC on something that ICC can't cope with.
to do it use a very large RAM disk loaded from the flash, which you then either batch copy into the flash FS at intervals, or at shutdown. (The latter is more likely as DRAM is as cheap or cheaper than Compact Flash capacity-wise).
Hence the flash is really only there to help it between power cycles, or to "back" in-flight data.
I could probably find one... but there should be a flash/RAM fs that does mostly everything in memory with an update-to-backing-flash-at-interval feature. Or you could somehow tune the buffer cache to be _really_ lazy about when it gets around to writing, and only to write in huge sequential blocks.