Yeah, and a heckuva lot of people now know Z80 ASM. Why? Because the TI-82,83,83+,85, and 86 graphing calculators -- err, portable monochrome game consoles that you can sometimes use in math class -- have Z80s at their cores. See ticalc.org for some info.
I heard Rob was going to release SlashLinux after reading this site, but then Signal 11 reminded him about the 24-hour policy, and he decided to delay it indefinately.
Thank you very much, but if I had moderator points I would have moderated you "Redundant".
I have noted a few errors in my first post that I wish to correct.
First, the signal that can be carried using COFDM is not exactly the same as the signal for 8-VSB. In fact, the bandwidth is adjustable up to about 20 Mb/s, but sacrificing some signal reliability. As I said, this can be tuned for the specific scenario.
Also, there are reasons not to go with COFDM as a single standard format. But there are no technical reasons not to consider it as an alternative. A major concern is that adopting COFDM even as an alternative system would slow DTV reception. Possibly, but do we want an inferior system?
Somebody wrote a bc(1) replacement in... AWK! I'm not linking to it here because it was so cool that they distributed it with the package. On Debian systems it can be found in/usr/doc/awk/examples. It can even do square roots. I would like to know what its algorithms are, but talk about obfruscated... everything except the few comments are either strings of incomprehensible symbols, or strings of letters in no particular order that I can discern. Even if I did know awk, trying to understand how it works would still elicit an "awk!" from just about anyone except the author.
Next project: port Linux to a Turing machine. Then I could run it on my TI-89 calculator, in the Turing machine simulator I wrote...
Seriously, if someone wants to try that, for it to be at all useful, you would need to define extensions to the normal TM functionality to handle things like keyboard and monitor IO. Maybe these could be added as states in the state machine. It would also be useful for the simulator to be a multi-track TM, knowing that a single-track TM can simulate a multi-track TM so there is no change in computing power, just ease of coding.
The reason Beta was not adopted over VHS was because of a phenomenon Bill Gates calls a positive feedback cycle. Such a cycle requires a critical mass of owners of a product to be present. A critical mass is not yet present in digital television. Only a small percentage of US households now have digital television receivers. For those with set-top boxes, the change to allow COFDM as an alternative format would require either purchasing a new box, or upgrading the old one with a Flash ROM upgrade, if it has such facilities. For those with a television with a built-in receiver, it is always possible to buy a set-top box and then plug it into the television's auxiliary inputs. It's not like allowing COFDM will instantly break all of what little is currently out there.
I had a full reply to your post, but Mozilla crashed right as I was about to hit "Submit":-(.
First, your link doesn't work.
Sinclair is not doing independant research like the FCC did for the nine years it took to hammer out the current standard.
Okay, and research like that is what Sinclair asked for in its petition to the FCC. For more information, see the link in my first post.
In order to attempt to be impartial, the advantages that are often given to 8-VSB are an increased bitrate (19.4 Mb/s instead of 18.6 for COFDM) and less transmission power requirements. The latter is given extensive discussion in the FAQ I referred to in my first post. As for bitrate, it's only a 4.1% reduction, hardly a reason to abandon a format. The bitrate determines the maximum quality of the transmitted picture, so this would translate into a 4.1% worse picture. On the other hand, many people have to look very hard to see a difference between 480p and 1080i. Remember also that the amount of extra coding in COFDM is variable, allowing tuning of the bitrate to reliability ratio to match expected viewership.
Although Sinclair's first tests were done using first generation receivers, newer receivers have been tested by Sinclair and others, and although ease of reception was improved, the promises of "solving the 8-VSB multipath problem" have not yet materialized enough to convince Sinclair, NBC, and other broadcasters to jump back on the 8-VSB bandwagon.
Sinclair does not sell transmitters at all. Acrodyne, in which Sinclair owns significant stock, does make and sell transmitters, but a transmitter does not carry with it the requirement to transmit only a certain format -- the exciter does. There should be no concerns of Sinclair or Acrodyne that do not apply to all companies in their respective markets.
... sales of existing televisions and existing broadcast equipment will fall through the floor.
Yes, but there isn't that much that's currently being sold. Besides, all Sinclair is asking -- asked, rather -- for is that COFDM be accepted as an alternative to 8VSB. This would not mandate any change, but only allow the option for consumers and broadcasters.
And, it's not like you can just change a cheap component and be done.
Well maybe it might not be cheap, but it is only one component for the broadcaster and a new set-top box for the consumer. That's why you should buy TVs with separate boxes now. And yes, current receivers are expensive, but if previous technology introductions are any model, that will change. Smaller, cheaper, better, as they say.
But the root of the matter is this: NTSC was always worse than PAL, and people knew this. The only reason that they couldn't improve the format was that too many people were already using NTSC. Do we want history to repeat itself? Sure it might be a pain now, but what the US decides now is what it is probably going to live with for the next up to 100 years conceivably. And now, broadcast television needs even more of a benefit to compete with cable, satellite, and internet data sources. This is why we need to switch to COFDM now!
To convert to COFDM will require changing only one component of the transmitter, and a new set-top box for the few people who currently have them. Act now before there are too many people using the existing, inferior system. (Plus If You Act Now... that even has its own acronym -- PIYAN:-)
One of the problems for DTV, and the major reason that reception is currently spotty, is the current transmission standard. 8VSB, as the current standard is called, is flawed. See my earlier article for some information, and find more thanks to Google.
COFDM is clearly the better solution. This was a major topic of discussion at this year's NAB, and a demonstration by Acrodyne of a COFDM signal transmitted from ~17 miles away being received in the convention center without any problems showed this quite well, as did Sinclair's earlier testing in Baltimore, which I discussed in my article; see above.
This is seriously not a troll, but instead, I think, a wake-up call. Another poster asked if you would want to trust your data to spotty reception. There is no reason to. With superior "ease of reception" in metropolitan areas, or other areas with a lot of multipath, or "ghosting", and equal or better reception outside of the city, there is no reason not to go with COFDM.
A bit of the science behind it: 8VSB uses one carrier that carries all of the information, which is typically MPEG-encoded video. COFDM carries the exact same information split up into many carriers across the 6 MHz spectrum given to a television station. If one of those carriers is somehow damaged, other carriers containing duplicates of that information can be used. The amount of duplicate data can easily be adjusted at the transmission side, allowing for the most data during non-peak hours (for use by data and multiple virtual channels), but increased signal reliability during prime time.
By the way, some xDSLs (which?) use (C)OFDM. Many mobile communications systems either are currently or will in the future use a multi-carrier system like COFDM.
But they're all on the same screen, and even though they might be minimized, the screen still tends to get cluttered. People often like to think in terms of separate workspaces. For example, I like to keep all of my Slashdot and Slashdot-referred windows on one X desktop, so I can easily separate out my geeky activities from one another as well as from my non-geeky activities (uh, um...). A simple Alt+Function Key brings me to the desktop I want and immediately everything is restored to the way it was when I left. The side effect of this is that I don't forget what I did something for. I mentally attach a context to each desktop, often backed up by other windows there, that helps me more quickly to task switch when the time comes.
As for real multitasking, i.e., at the kernel level, there are some nice things about the Windows model, including native threads and such, but (a) a common use of Windows threads is to wait on file and socket input at the same time, which Unix allows you to do without forking, and (b) what could be simpler than fork(); exec();? Sure it makes some things harder, but it's less for the programmer to think about, less doubting what to pass to a certain function (although the Windows thread-management functions aren't as hard as other Windows functions as far as arguments), and less stuff (thread IDs, etc.) for the parent process to keep track of. Basically the fork() splits off a separate entity that initially has some ties to its sibling, but can break these ties and in many cases split off completely on its own. Thus sort of flexibility can be achieved with threads, but it's a pinch. And besides, the Windows process scheduler needs to remove that favoring of the top window (NT: don't enable a screensaver... why? it gets priority over server processes!).
feature from whose point of view? For example, I am behind an IP Masq. NAT gateway, and thus any number of computers could be accessing Slashdot from the same IP. This wasn't a problem in my case, but considering that many corporate servers and conceivably any number of cheap ISPs could be doing proxying or masquerading, this could knock out a heck of a lot of legitimate posts and moderations. Oh well...
Thats it..its over. sean_k from #i-opener-linux has devolped a program to decrypt ANY qnx password. Because of this we were able to extract these passwords:
Root: osiw$6.4 Regular user: one2go Thanks to everone who helped him. Source to the program is here
Doom? I thought the Word easter egg was a pinball game (Word 97 -- which version are you talking about?) To get to Word 97 Pinball (a POS, but still...), open a new instance, sent font color to Blue, size Bold, (size 12??? not sure), and type Blue (capital B, space at the end). Go to Help, About and click on the envelope under the W.
btw, the Excel flight simulator is also easy to get. Again in a new instance, press F5 (Goto) and type the range x97:l97. Press Enter and the range starting at L97 is selected. Press Tab to move the cursor one cell to the right. Then hold down Ctrl and Shift while you click on the Chart Wizard button on the tool bar. Left mouse button accelerates, right button decelerates or accelerates in reverse. Look for and laugh at the scrolling text box ("In the beginning, there was nothing. Then there was Microsoft Excel. (well there were some other versions of Excel before that." (other stuff follows; I can't remember off the top of my head)) and the messed-up wavy lake (as my friend Jeremy Best called it). Have fun, but remember to restart Windows and boot into Linux sooner than later.
Internet-2: FreeNet or VPN? Well FreeNet is leaning more on the Usernet side, but is a mix of the two, but that's probably what you meant to be thinking of. Sure there will be idiots on FreeNet, but they won't be in control.
If it's DirectPlay, which is part of DirectX, that is having a lot of problems with masq'ed connections, would Khronos help (Slashdot story here)? Just wondering... since it'll be an open replacement for DirectX, why not include an open replacement for DirectPlay? (Better yet: make a source-compatible wrapper, and no game company would have any excuse!)
You can grab my modified encoder (OggSquish, for significant lack of a better name) here (I have to link to my main site unless you can set your referrer HTTP tag to be somewhere at kcarnold.freeservers.com -- freeservers.com rule so they can make you see ads). Mozilla M14 seems to have trouble with this (doesn't set the referrer tag right), so you may havet to try Netscape, Opera, w3m, lynx, or (*gasp*) Internet Explorer.
Really weird -- I was just looking at their site when I reloaded Slashdot.
There is an encoder available in the CVS checkout from the xiph.org site. However, it is extremely simplistic. I have already added to this encoder the ability to accept command line options via getopt(). My modifications seem reasonably stable and I will be releasing the modified encoder to Freshmeat probably within the day. Really this makes it much easier to encode things (the supplied encoder is stdin -> stdout). I plan on doing the same thing with the decoder so that it can play to the sound card, etc., like mpg123. I will link to my modified source as soon as I get it online.
The xmms plugin: in the cvs directory xmms, just type 'make' (after configuring and making the rest of the package from the main directory). Then copy the resulting lib*.so file to your XMMS Input plugins directory (/usr/lib/xmms/Input/ for global, ~/.xmms/plugins/Input ??? for local.)
Either I missed the end, but I thought that the end was backing out of another holographic recreation and the guide saying how that was the beginning of amicable relationships among the two groups or something like that -- nothing about Harry Kim that I remember -- though it was a long time ago.
You couldn't pay me Bill Gates's wealth to remember the name, but I do remember one Voyager episode in which the Doctor (a hologram, if you never watched Voyager) is found among the Voyager wreckage on some planet, several hundred years after what is probably the end of the series. This confirms that Voyager doesn't make it back home, but if I remember it right, there's nothing saying that her crew did not escape unharmed. Also, I don't think they gave a location for the planet, so it could have been quite close to home.
If you want to know the basics of how the kernel ticks, it might be useful to investigate the ELKS project [they need a shorter URL!]. They say that the subset is "small enough to be understood by one person", which I think is what you're looking for. It doesn't have all the drivers, support layers, etc. in the "real" kernel, and the internal structure may be different in important ways, but still it should help you see what's going on.
Slashdot Mirror
Like...? (honestly-asking-for-suggestions-here look)
Thank you very much, but if I had moderator points I would have moderated you "Redundant".
First, the signal that can be carried using COFDM is not exactly the same as the signal for 8-VSB. In fact, the bandwidth is adjustable up to about 20 Mb/s, but sacrificing some signal reliability. As I said, this can be tuned for the specific scenario.
Also, there are reasons not to go with COFDM as a single standard format. But there are no technical reasons not to consider it as an alternative. A major concern is that adopting COFDM even as an alternative system would slow DTV reception. Possibly, but do we want an inferior system?
Next project: port Linux to a Turing machine. Then I could run it on my TI-89 calculator, in the Turing machine simulator I wrote...
Seriously, if someone wants to try that, for it to be at all useful, you would need to define extensions to the normal TM functionality to handle things like keyboard and monitor IO. Maybe these could be added as states in the state machine. It would also be useful for the simulator to be a multi-track TM, knowing that a single-track TM can simulate a multi-track TM so there is no change in computing power, just ease of coding.
Kenneth
The reason Beta was not adopted over VHS was because of a phenomenon Bill Gates calls a positive feedback cycle. Such a cycle requires a critical mass of owners of a product to be present. A critical mass is not yet present in digital television. Only a small percentage of US households now have digital television receivers. For those with set-top boxes, the change to allow COFDM as an alternative format would require either purchasing a new box, or upgrading the old one with a Flash ROM upgrade, if it has such facilities. For those with a television with a built-in receiver, it is always possible to buy a set-top box and then plug it into the television's auxiliary inputs. It's not like allowing COFDM will instantly break all of what little is currently out there.
Kenneth
First, your link doesn't work.
Sinclair is not doing independant research like the FCC did for the nine years it took to hammer out the current standard.
Okay, and research like that is what Sinclair asked for in its petition to the FCC. For more information, see the link in my first post.
In order to attempt to be impartial, the advantages that are often given to 8-VSB are an increased bitrate (19.4 Mb/s instead of 18.6 for COFDM) and less transmission power requirements. The latter is given extensive discussion in the FAQ I referred to in my first post. As for bitrate, it's only a 4.1% reduction, hardly a reason to abandon a format. The bitrate determines the maximum quality of the transmitted picture, so this would translate into a 4.1% worse picture. On the other hand, many people have to look very hard to see a difference between 480p and 1080i. Remember also that the amount of extra coding in COFDM is variable, allowing tuning of the bitrate to reliability ratio to match expected viewership.
Although Sinclair's first tests were done using first generation receivers, newer receivers have been tested by Sinclair and others, and although ease of reception was improved, the promises of "solving the 8-VSB multipath problem" have not yet materialized enough to convince Sinclair, NBC, and other broadcasters to jump back on the 8-VSB bandwagon.
Sinclair does not sell transmitters at all. Acrodyne, in which Sinclair owns significant stock, does make and sell transmitters, but a transmitter does not carry with it the requirement to transmit only a certain format -- the exciter does. There should be no concerns of Sinclair or Acrodyne that do not apply to all companies in their respective markets.
Kenneth
Yes, but there isn't that much that's currently being sold. Besides, all Sinclair is asking -- asked, rather -- for is that COFDM be accepted as an alternative to 8VSB. This would not mandate any change, but only allow the option for consumers and broadcasters.
And, it's not like you can just change a cheap component and be done.
Well maybe it might not be cheap, but it is only one component for the broadcaster and a new set-top box for the consumer. That's why you should buy TVs with separate boxes now. And yes, current receivers are expensive, but if previous technology introductions are any model, that will change. Smaller, cheaper, better, as they say.
But the root of the matter is this: NTSC was always worse than PAL, and people knew this. The only reason that they couldn't improve the format was that too many people were already using NTSC. Do we want history to repeat itself? Sure it might be a pain now, but what the US decides now is what it is probably going to live with for the next up to 100 years conceivably. And now, broadcast television needs even more of a benefit to compete with cable, satellite, and internet data sources. This is why we need to switch to COFDM now!
To convert to COFDM will require changing only one component of the transmitter, and a new set-top box for the few people who currently have them. Act now before there are too many people using the existing, inferior system. (Plus If You Act Now... that even has its own acronym -- PIYAN :-)
COFDM is clearly the better solution. This was a major topic of discussion at this year's NAB, and a demonstration by Acrodyne of a COFDM signal transmitted from ~17 miles away being received in the convention center without any problems showed this quite well, as did Sinclair's earlier testing in Baltimore, which I discussed in my article; see above.
This is seriously not a troll, but instead, I think, a wake-up call. Another poster asked if you would want to trust your data to spotty reception. There is no reason to. With superior "ease of reception" in metropolitan areas, or other areas with a lot of multipath, or "ghosting", and equal or better reception outside of the city, there is no reason not to go with COFDM.
A bit of the science behind it: 8VSB uses one carrier that carries all of the information, which is typically MPEG-encoded video. COFDM carries the exact same information split up into many carriers across the 6 MHz spectrum given to a television station. If one of those carriers is somehow damaged, other carriers containing duplicates of that information can be used. The amount of duplicate data can easily be adjusted at the transmission side, allowing for the most data during non-peak hours (for use by data and multiple virtual channels), but increased signal reliability during prime time.
By the way, some xDSLs (which?) use (C)OFDM. Many mobile communications systems either are currently or will in the future use a multi-carrier system like COFDM.
For a bit more information, see Sinclair's COFDM FAQ.
Kenneth
As for real multitasking, i.e., at the kernel level, there are some nice things about the Windows model, including native threads and such, but (a) a common use of Windows threads is to wait on file and socket input at the same time, which Unix allows you to do without forking, and (b) what could be simpler than fork(); exec();? Sure it makes some things harder, but it's less for the programmer to think about, less doubting what to pass to a certain function (although the Windows thread-management functions aren't as hard as other Windows functions as far as arguments), and less stuff (thread IDs, etc.) for the parent process to keep track of. Basically the fork() splits off a separate entity that initially has some ties to its sibling, but can break these ties and in many cases split off completely on its own. Thus sort of flexibility can be achieved with threads, but it's a pinch. And besides, the Windows process scheduler needs to remove that favoring of the top window (NT: don't enable a screensaver... why? it gets priority over server processes!).
From http://www.i-opener-linux.net/:
Thats it..its over. sean_k from #i-opener-linux has devolped a program to decrypt ANY qnx password. Because of this we were able to extract these passwords:
Root: osiw$6.4
Regular user: one2go
Thanks to everone who helped him. Source to the program is here
btw, the Excel flight simulator is also easy to get. Again in a new instance, press F5 (Goto) and type the range x97:l97. Press Enter and the range starting at L97 is selected. Press Tab to move the cursor one cell to the right. Then hold down Ctrl and Shift while you click on the Chart Wizard button on the tool bar. Left mouse button accelerates, right button decelerates or accelerates in reverse. Look for and laugh at the scrolling text box ("In the beginning, there was nothing. Then there was Microsoft Excel. (well there were some other versions of Excel before that." (other stuff follows; I can't remember off the top of my head)) and the messed-up wavy lake (as my friend Jeremy Best called it). Have fun, but remember to restart Windows and boot into Linux sooner than later.
There is an encoder available in the CVS checkout from the xiph.org site. However, it is extremely simplistic. I have already added to this encoder the ability to accept command line options via getopt(). My modifications seem reasonably stable and I will be releasing the modified encoder to Freshmeat probably within the day. Really this makes it much easier to encode things (the supplied encoder is stdin -> stdout). I plan on doing the same thing with the decoder so that it can play to the sound card, etc., like mpg123. I will link to my modified source as soon as I get it online.
The xmms plugin: in the cvs directory xmms, just type 'make' (after configuring and making the rest of the package from the main directory). Then copy the resulting lib*.so file to your XMMS Input plugins directory (/usr/lib/xmms/Input/ for global, ~/.xmms/plugins/Input ??? for local.)
Well what do you know -- I found it: Living Witness