Absodiddlyutely. Floating point isn't arithmetic, it's a *simulation of* arithmetic. Alan Turing [and probably others] pointed this out before 1950! It trades precision for convenience and dynamic range. RTFM!
Oh no, holy asynchronicity BatMammal! What we need is an external device -- let's call it a clockyticker -- no, a timer! and a high-tech internal mechanism, lessee, a frobulator -- NO! -- let's call it interrupts! Yes! When the timer goes R-R-R-R-RING! -- we cause program execution at a predetermined point in the program! Wow, I'll make millions!
As one of the victims of this horrible plot, I have to admit it's pretty good. OK it makes me look good, which is probably an accident or mistake; but it does present some of FidoNet's complexities in a realistic, non-trivial-making light. Which is not easy.
For better or worse, things are NOT oversimplified to make a digestable story, which probably took a lot of nerve on Jason's part. Simple linear stories probably sell better:-)
Pay the S.O.B. his money; this isn't some issue from Microsoft, but Some Guy who produced this work on his own dime. And years of time. There are probably better ways for Jason to get Rich or Famous, but this adds more to culture. (Oh that.)
I run SuSE, 2.6 kernel on a Sony VX 88 laptop that doesn't work with swsusp. I halved my boot time by disabling the following daemons and running this script once up.
Apparently, lots of people are thinking along these same lines (only devoting more useful brain cells than I:-) I think I'll start looking at this for real...
Oh please, more likely the two years is the limit of the authors pedantic 'knowledge'.
ARPANET/Internet. USENET. FidoNet. Bulletin Board Systems (BBS) software, the sole purpose of which to build electronic meetingplaces, since the late 1970's. And countless machine-local 'mail' type systems on computers back to the earliest if the 1960's.
I believe it's like this: a system of "tokens" that are computationally hard to create, so if your machine can re-use a token it's received from someone else, it saves a lot of time.
The server system restricts "reuse" of tokens in a way that prevents simple copy/duplication. That's all the underlying crypto stuff. An analogy is, you receive token "N" from some email, and save it for later. TO send email, you need a token -- grab one saved from before. Crypto code at a central server (ERRT!) performs (verifyable) magic to make that used token "N" into new, unused token "N+1".
You *can* print credible paper money, but it's really hard. Most people find better ways. That's the idea behind it.
ERRT: but doesn't this mean that the "issuing" server needs to be involved in every re-use transaction, foiling one of the beauties of SMTP mail: utter decentralization?
* Hydrogen isn't a "fuel" here, it's short-term energy storage. The very concept of "fuel" is 19th century, get over it.
* LONG TERM RELIABILITY is likely a massive goal here, not slashdot sweetness.
* Batteries are an inefficient chemical transformation too, plus are messy, expensive, wear out, require frequent replacements, and are technically very fussy. A big empty metal tank is CHEAP, RELIABLE and MAINTAINABLE.
* Household systems have gotta be simple, reliable, not prone to spectacular failure when prodded by know-nothing owners and repairmammals, installable by Home Depot employees. Hence the apparent lack of gimcrackery; the smarts, where present, are in the design.
* Likely, efficiencies gained by using PV electrical during the day and stored H2 at night are offset by additional system complexity in switching between the two. I bet the optimization wouldn't gain more than 10% or so and at greatly increased cost.
* Hydrogen is the most common element in the UNIVERSE. He may have misspoke, but he's not an idiot.
* No system will have universal application. Because it's not good in E. Overshoe Alaska doesn't mean it's worthless. My laptop fares poorly underwater, blame Sony. Hell, simple apses and shade would save billions in cooling costs in the SouthWest U.S., and requires only cave-mammal tech, but a few extra brain cells which seem to be in short supply in the building industry.
* Stop looking for a single "magic bullet" technology that will "solve the world's X crisis" foreach X (list); -- what, are you reading the pamphlet from the 1939 World's Fair or something? Broad based tuning of widespread systems is where it's at. Or would be, if corporate profits weren't the only goal of the western world. How embarrassing for us.
* "Fully sustaining" was a poor phrase to choose, he should be called on that, but see above elsewise.
peer-to-peer is a lovely idea, but without authentication it quickly becomes a cesspool.
every up2date client has a certificate to authenticate the connection (to redhat) and a GPG public key to verify each package; you can reasonably assume the packages are what they claim to be.
gnutella (et al) vs. up2date: which do you trust to find (RedHat) kernel updates?
bittorrent minimizes the 'slashdot effect', and it's our intent to build it in.
combined, this hopefully makes distribution of RPMs pretty nice, and a good starting point for a more general file distribution system.
one step at a time, no pushing please.
tomj
PS: no thing solves all problems.
Display technologies, clocks, associated crapola
on
Build A Nixie Tube Clock
·
· Score: 4, Interesting
Yes, technologically, Nixies & related are a pain to interface to +5V CMOS logic, but that's not the point. LCDs are clearly superior in sooo many ways, but they are... well, boring.
Pretty much all instrumentation these days looks the same, membrane switch, LCDs, a few LEDs, a pile of nifty software, an order-of-magnitude more accurate than the previous model, runs on a AA cell for 2 years until you throw it out.
However, our lovely bodies are physical, and they like being enticed with 'interface' (sic) that connects with more than just yore brane. You can *touch* nixies, the glass is nice to touch, and so are heavy bakelite knobs, switches you can *feel* change state.... Nixie digits jump around. The orange color works well with your eyes. There's no blinky multiplex updates to dazzle.
In general, pre-photomicrolithography electronic stuff was more fun to touch and use (though largely sucked when it came to power consumption, reliability, size, heat output, portability, ad nauseum) as is quite obvious.
A Tektronix scope is an excellent example of technology and interface design and of paradigms lost -- they use first-principle physics (the cathode ray tube is more than just a display, it's an integral measurement component), a mixture of solid-state and state-of-the-art electron tubes, analog computing components (verniers), big clicky knobs, coded by color, size, shape and placement, nice colors and shape, a manual that contains data and meta-data (operating, maintenance, design! and curious gratuitous cartoon graphic characters walking along signal paths...) Like other targetd instrumentation, it embodied and defined a culture of use that was far more... fun.
But performance-wise, my TDS-220 software'n'LCD 100MHz BW gigasample scope, the size of an old table radio, is incomparable. It's a pretty amazing contrast for only 30 years of development.
But now we get the best of both worlds (sic), teensy micros under the nice part of the old stuff. I think it's a pretty normal development, culturally, this re-use of the "outsides" of old equipment to achieve a revisionist view.
Interface is always where the interesting stuff is.
The best nixie and 'scope clock technology out there today, is hands-down, David's (http://www.cathodecorner.com), surface mount, AC power line isolation, small, low-power, software driven, switcher HV supply, reasonable price (no I get no kickback frmo his sales).
I wrote a brief history of nixie and decimal tube history here: http://wps.com/texts/decimal-tubes/index.html, nothing exhaustive, but a good start.
For home-brew, a transformer/diode bridge/series regulator with zener is somewhat crude, but easy to make, reliable, and reasonably low power. For a transformer I use a Thordarson-Meissner # 26R60 transformer from Allied Electronics (web order) around $19 each (provides 6.3V and 150V outputs). This is no where near as elegant as David's but for one-off it's fine.
I too make clocks (http://wps.com/products) but I'm not in the clock business per se, mine are simply art (more accurately craft) objects, though I'll make more. My emphasis is more on a functional, tactile artifact, a Nice Thing to hold and use. I've only made a half dozen so far, I've got another half-dozen in the works. After I use up my stock of PCBs I'll end up buying guts from David, it's a much better design.
Yes, EDSAC's (the 2nd stored-prog) computer ever run) initial orders DO count, besides, there were symbolic subroutine linkers and standard libraries assembled into programs with variably resident software.
Andrew Booth's drum machines had chunks of drum with callable subroutines that were left in standard locations, eg. resident I/O and such. Most definitely an OS, and that was 1948? 1950? I can look if anyone cares.
Clearly, from the replies here many think an "OS" must have a keyboard and display and accept commands entered by a human for immediate execution.
Hell, even I've used minis (Nova, PBP-8, Varian 622/i, whatever) that used core-resident code that talked through the front panel only (though the teletype was better). They were the equiv. of modern embedded-controller OSs.
The Soviet BESMs were real and early machines, and had real OSs too, 1950? 1949?
If you define an operating system as a collection of routines that provide abstract services on the underlying hardware (eg. I/O, stdlib-type stuff) and/or software that helps the programmer/user write and debug programs, then the answer is easy: 1945.
The first detailed implementation description I've read is Alan Turing's "ACE REPORT" from late 1945. In it he describes software libraries, linking loaders, subroutine linkages, and describes the need for (human) librarians to manage and document standard routines, etc.
The first running stored-program computer (Manchester "Baby", 1948) had no OS, since it had only 1024 bits of memory (!) and was more of a 'contest winner' than a functional machine, but easily, all of the first real, pre-1950 machines had system software about 15 minutes after someone tried to code to the hardware.
(I hereby declare it OK to say Turing's ACE code was first even if it didn't get 'compiled' until much later. ('Source code' was written in 1945.) The computer industry as a whole has preannounced availability right from the start.)
vonNeumann may have trumped Turing by a few months on publication, but I can't yet find the Appendices to the "EDVAC REPORT", which makes no mention of such things. In any case, the depth and breadth of Turing's vision of computers as general-purpose, symbolic manipulators beats the shit out of everyone, up until the 1960's. Really, read the "ACE REPORT", it's shockingly modern (once you get past his frumpy British language).
I assume we're talking only about "stored program automatic digital computers" also.
-- tomj@wps.com
http://wps.com
Slashdot Mirror
Absodiddlyutely. Floating point isn't arithmetic, it's a *simulation of* arithmetic. Alan Turing [and probably others] pointed this out before 1950! It trades precision for convenience and dynamic range. RTFM!
Oh no, holy asynchronicity BatMammal! What we need is an external device -- let's call it a clockyticker -- no, a timer! and a high-tech internal mechanism, lessee, a frobulator -- NO! -- let's call it interrupts! Yes! When the timer goes R-R-R-R-RING! -- we cause program execution at a predetermined point in the program! Wow, I'll make millions!
For better or worse, things are NOT oversimplified to make a digestable story, which probably took a lot of nerve on Jason's part. Simple linear stories probably sell better
Pay the S.O.B. his money; this isn't some issue from Microsoft, but Some Guy who produced this work on his own dime. And years of time. There are probably better ways for Jason to get Rich or Famous, but this adds more to culture. (Oh that.)
Laptops. They boot often. My servers it matters not. Laptops. I know about swsusp. Laptops still boot "often".
I run SuSE, 2.6 kernel on a Sony VX 88 laptop that doesn't work with swsusp. I halved my boot time by disabling the following daemons and running this script once up.
:-) I think I'll start looking at this for real...
;;
Apparently, lots of people are thinking along these same lines (only devoting more useful brain cells than I
foo) echo "Start"
sudo rcpcmcia start
sudo rcnetwork start
sudo rcSUSEfirewall2_final start
sudo rcsshd start
sudo rccron start
sudo rcpostfix start
sudo rcsane start
sudo rcxntpd start
sudo rcresmgr start
sudo rclpd start
sudo rcrpmconfigcheck start
sudo rcalsasound start
Well duh, because *humans* going to space is interesting. Though likely their food will be better.
These sorts of sound-bite truisms are just as often wrong. The world just isn't that ordered.
ARPANET/Internet. USENET. FidoNet. Bulletin Board Systems (BBS) software, the sole purpose of which to build electronic meetingplaces, since the late 1970's. And countless machine-local 'mail' type systems on computers back to the earliest if the 1960's.
I believe it's like this: a system of "tokens" that are computationally hard to create, so if your machine can re-use a token it's received from someone else, it saves a lot of time.
The server system restricts "reuse" of tokens in a way that prevents simple copy/duplication. That's all the underlying crypto stuff. An analogy is, you receive token "N" from some email, and save it for later. TO send email, you need a token -- grab one saved from before. Crypto code at a central server (ERRT!) performs (verifyable) magic to make that used token "N" into new, unused token "N+1".
You *can* print credible paper money, but it's really hard. Most people find better ways. That's the idea behind it.
ERRT: but doesn't this mean that the "issuing" server needs to be involved in every re-use transaction, foiling one of the beauties of SMTP mail: utter decentralization?
* DUH! if it contains energy it's dangerous.
* Hydrogen isn't a "fuel" here, it's short-term energy storage. The very concept of "fuel" is 19th century, get over it.
* LONG TERM RELIABILITY is likely a massive goal here, not slashdot sweetness.
* Batteries are an inefficient chemical transformation too, plus are messy, expensive, wear out, require frequent replacements, and are technically very fussy. A big empty metal tank is CHEAP, RELIABLE and MAINTAINABLE.
* Household systems have gotta be simple, reliable, not prone to spectacular failure when prodded by know-nothing owners and repairmammals, installable by Home Depot employees. Hence the apparent lack of gimcrackery; the smarts, where present, are in the design.
* Likely, efficiencies gained by using PV electrical during the day and stored H2 at night are offset by additional system complexity in switching between the two. I bet the optimization wouldn't gain more than 10% or so and at greatly increased cost.
* Hydrogen is the most common element in the UNIVERSE. He may have misspoke, but he's not an idiot.
* No system will have universal application. Because it's not good in E. Overshoe Alaska doesn't mean it's worthless. My laptop fares poorly underwater, blame Sony. Hell, simple apses and shade would save billions in cooling costs in the SouthWest U.S., and requires only cave-mammal tech, but a few extra brain cells which seem to be in short supply in the building industry.
* Stop looking for a single "magic bullet" technology that will "solve the world's X crisis" foreach X (list); -- what, are you reading the pamphlet from the 1939 World's Fair or something? Broad based tuning of widespread systems is where it's at. Or would be, if corporate profits weren't the only goal of the western world. How embarrassing for us.
* "Fully sustaining" was a poor phrase to choose, he should be called on that, but see above elsewise.
peer-to-peer is a lovely idea, but without authentication it quickly becomes a cesspool.
every up2date client has a certificate to authenticate the connection (to redhat) and a GPG public key to verify each package; you can reasonably assume the packages are what they claim to be.
gnutella (et al) vs. up2date: which do you trust to find (RedHat) kernel updates?
bittorrent minimizes the 'slashdot effect', and it's our intent to build it in.
combined, this hopefully makes distribution of RPMs pretty nice, and a good starting point for a more general file distribution system.
one step at a time, no pushing please.
tomj
PS: no thing solves all problems.
Yes, technologically, Nixies & related are a pain to interface to +5V CMOS logic, but that's not the point. LCDs are clearly superior in sooo many ways, but they are... well, boring.
... fun.
Pretty much all instrumentation these days looks the same, membrane switch, LCDs, a few LEDs, a pile of nifty software, an order-of-magnitude more accurate than the previous model, runs on a AA cell for 2 years until you throw it out.
However, our lovely bodies are physical, and they like being enticed with 'interface' (sic) that connects with more than just yore brane. You can *touch* nixies, the glass is nice to touch, and so are heavy bakelite knobs, switches you can *feel* change state.... Nixie digits jump around. The orange color works well with your eyes. There's no blinky multiplex updates to dazzle.
In general, pre-photomicrolithography electronic stuff was more fun to touch and use (though largely sucked when it came to power consumption, reliability, size, heat output, portability, ad nauseum) as is quite obvious.
A Tektronix scope is an excellent example of technology and interface design and of paradigms lost -- they use first-principle physics (the cathode ray tube is more than just a display, it's an integral measurement component), a mixture of solid-state and state-of-the-art electron tubes, analog computing components (verniers), big clicky knobs, coded by color, size, shape and placement, nice colors and shape, a manual that contains data and meta-data (operating, maintenance, design! and curious gratuitous cartoon graphic characters walking along signal paths...) Like other targetd instrumentation, it embodied and defined a culture of use that was far more
But performance-wise, my TDS-220 software'n'LCD 100MHz BW gigasample scope, the size of an old table radio, is incomparable. It's a pretty amazing contrast for only 30 years of development.
But now we get the best of both worlds (sic), teensy micros under the nice part of the old stuff. I think it's a pretty normal development, culturally, this re-use of the "outsides" of old equipment to achieve a revisionist view.
Interface is always where the interesting stuff is.
The best nixie and 'scope clock technology out there today, is hands-down, David's (http://www.cathodecorner.com), surface mount, AC power line isolation, small, low-power, software driven, switcher HV supply, reasonable price (no I get no kickback frmo his sales).
I wrote a brief history of nixie and decimal tube history here: http://wps.com/texts/decimal-tubes/index.html, nothing exhaustive, but a good start.
For home-brew, a transformer/diode bridge/series regulator with zener is somewhat crude, but easy to make, reliable, and reasonably low power. For a transformer I use a Thordarson-Meissner # 26R60 transformer from Allied Electronics (web order) around $19 each (provides 6.3V and 150V outputs). This is no where near as elegant as David's but for one-off it's fine.
I too make clocks (http://wps.com/products) but I'm not in the clock business per se, mine are simply art (more accurately craft) objects, though I'll make more. My emphasis is more on a functional, tactile artifact, a Nice Thing to hold and use. I've only made a half dozen so far, I've got another half-dozen in the works. After I use up my stock of PCBs I'll end up buying guts from David, it's a much better design.
Andrew Booth's drum machines had chunks of drum with callable subroutines that were left in standard locations, eg. resident I/O and such. Most definitely an OS, and that was 1948? 1950? I can look if anyone cares.
Clearly, from the replies here many think an "OS" must have a keyboard and display and accept commands entered by a human for immediate execution.
Hell, even I've used minis (Nova, PBP-8, Varian 622/i, whatever) that used core-resident code that talked through the front panel only (though the teletype was better). They were the equiv. of modern embedded-controller OSs.
The Soviet BESMs were real and early machines, and had real OSs too, 1950? 1949?
If you define an operating system as a collection of routines that provide abstract services on the underlying hardware (eg. I/O, stdlib-type stuff) and/or software that helps the programmer/user write and debug programs, then the answer is easy: 1945. The first detailed implementation description I've read is Alan Turing's "ACE REPORT" from late 1945. In it he describes software libraries, linking loaders, subroutine linkages, and describes the need for (human) librarians to manage and document standard routines, etc. The first running stored-program computer (Manchester "Baby", 1948) had no OS, since it had only 1024 bits of memory (!) and was more of a 'contest winner' than a functional machine, but easily, all of the first real, pre-1950 machines had system software about 15 minutes after someone tried to code to the hardware. (I hereby declare it OK to say Turing's ACE code was first even if it didn't get 'compiled' until much later. ('Source code' was written in 1945.) The computer industry as a whole has preannounced availability right from the start.) vonNeumann may have trumped Turing by a few months on publication, but I can't yet find the Appendices to the "EDVAC REPORT", which makes no mention of such things. In any case, the depth and breadth of Turing's vision of computers as general-purpose, symbolic manipulators beats the shit out of everyone, up until the 1960's. Really, read the "ACE REPORT", it's shockingly modern (once you get past his frumpy British language). I assume we're talking only about "stored program automatic digital computers" also. -- tomj@wps.com http://wps.com