I'm up to about page 460, having gotten it a few weeks ago. The commentary on the standard proper is interesting, if a bit verbose. I have a lot of reservations about the wisdom of the length of chapter 0, the psychological theory stuff the author seems to be trumpeting. The gist seems to be that people can be irrational and make silly mistakes, and confusing them doesn't help, and throwing more words at them may not help either. Then there follows 1500 or so pretty dense pages. I'm not sure that a few of the 2000 lines in the standard couldn't have gotten by with a few more "ditto the previous discussion" topics.
But, for the truly pedantic (like some of us who have been involved in C coding standards for 20 years), much of the detail is interesting. I'm not sure how much general audience there would have been at $90/copy. Graduate level seminars in the ecology and natural history of language standards development?
I just paid $8 of recycling fee on a new TV in california. I don't really mind, I guess, if this is in fact funding something that makes it relatively easy for me to recycle it later. I once went to a dump with one, and they wanted to charge me $15 or something like that to take it. I turned
around and left it on the curb for someone to take
instead.
What I fear is that this "fee" is really going to be tossed into the general fund, and no useful recycling program will be created. Then it's just a one-time TV purchase tax.
is that the TOE concept seemed to have been invented a long time ago. The "Excelan" tcp/ip ethernet from around 1984 comes to mind. See for example,
this, which says,
what about TOE?
TCP offload is an old answer,
- 1983 : Excelan i186-based "smart adapter"
- 1986 : CMC 68020
- Early 1990's : SGI
- Late 1990's : Adaptec, Alacritec...
Hey, there they are! Wonder what their "innovation" was that made it a better idea than the first few incarnations?
True; but the claim was that the DOS OS was the best - and it wasn't. It was just cheaper, and that was enough to drive the application ecosystem that direction. If CP/M 86 had been the same price as DOS, it would have wiped DOS.
That was Kildall's decision, and not really subject to IBM's whim or Bill's machinations. If DR had chosen to compete on price, they could have driven the market. Trying to be the "high value
justifies high cost" player in the PC market has shown itself to be a losing position, but that must not have been obvious at the time.
Secondly, in it's day, it was the best Operating system around for a PC, hands down. DOS brought device handling up front, to the user. It was a major step in the direction that all OS' follow now. Without that history, much of the device layer we are accustomed to today, wouldn't be there. I was a professional in the field then and it's creation opened so many doors. It was a cool time to be paid to work with the stuff.
I must say, I don't follow this at all. I actually used CP/M-86. which was superior to DOS of the same vintage in just about every way, except that it was $395 when DOS was $60. CP/M-86
was engineered in a way a professional could appreciate, while DOS felt (and was) whacked together.
And MP/M-86 was a really good system for it's time, very well engineered. Not as good as a similar vintage UNIX V7, but fairly comparable to RT-11.
A previous poster had it right. Rather than add more technology and an whole new infrastructure, the right thing to do is to raise the fuel taxes. This has the added advantage of further punishing those who don't get good milage, also likely those with heavier vehicles that do the most damage to the infrastructure.
There is good reason to make whatever is done a 'pay as you go' rather than a lump sum. Do you want to get hit with another huge whopping tax bill when your registration is up?
A "solution" sale leads one to higher "value based pricing", where a technology sale leads one to "cost based pricing".
For someone on the selling side, it's more profitable to sell value-based 'solutions' rather than technology where he has to compete on price.
For someone on the buying side, getting a "solution" may be more expensive, or it may be cheaper if one doesn't want to be ones own integrator and support department. You are basically paying for reduced hassle. The trick is quantifying the value of your own hassle, and the liklihood the 'solution' will have its own hassles, and their cost. Different people will evalutate these things differently.
I've worked at large firms that only hire fresh-outs from top-tier programs. I don't myself have a CS degree, and have risen on merit alone, but I started a long time ago. If I wanted an entry level job at such a firm now, I'd need to be from a top-N school. Resumes from other places tend not to be looked at very seriously unless there is some fantastic personal project to draw attention.
Being from a top-N school will open doors for your first job, and you may be better networked in school and for a while afterwards to opportunities. You may have better opportunity to try something that gets noticed to form your own startup (eg: Google). A lot of this depends on whether you stay for an MSCS as well.
If you are learning plenty now, and planning on
grad school, you might stay where you are and target a top-N school as the next step. If you
don't plan on grad school, and don't have a calling card project on which to hang your hat,
a prestige school won't hurt. Joe Schlemiel from Podunk Extension isn't going to get much attention
from many employers outside Podunk.
At the dawn of time, there were two other things called tiny c (small letters), by Scott Guthery d/b/a tiny-c Associates. Both ran on 8080 systems with small memories. One was an interpreter of a small C-like language, that came with full assembly for the interpreter, a listing of the C code from which the assembly was derived, and an excellent loose leaf binder explaining in detail how the whole thing worked. It was a recursive descent parser/interpreter.
I learned a lot from this package in 1980, even though I never had an 8080 to run it on. I hand coded it in assembler to run on Interdata machines instead. Still have the loose-leaf in the garage as a prized memento.
The other was a byte-code compiler for a slightly more expansive language. This ran faster, but I never bought it to see.
So I download the source to my Suse 9.x machine
with gcc 3.3.3, run configure:
./configure Binary directory/usr/local/bin Library directory/usr/local/lib Include directory/usr/local/include Manual directory/usr/local/man Doc directory/usr/local/share/doc/tcc Source path/home/dbrower/src/tcc-0.9.21 C compiler gcc make make CPU x86 Big Endian no gprof enabled no Creating config.mak and config.h config.h is unchanged
say make and get a compilation error:
gcc -O2 -Wall -c -o bcheck.o bcheck.c bcheck.c:172: error: conflicting types for `__bound_ptr_add' bcheck.c:80: error: previous declaration of `__bound_ptr_add' bcheck.c:231: error: conflicting types for `__bound_local_new' bcheck.c:87: error: previous declaration of `__bound_local_new' bcheck.c:247: error: conflicting types for `__bound_local_delete' ...
This is fixed by defining __TINYC__ in the rule for bcheck.o, and you get a tcc executable. Trying to remake it with itself
rm *.o make CC=tcc
Results in complaints about stddef.h not found. Adding -I/usr/include/linux leaves us with
other errors, and as Mr. Costello would say at this
point, "I don't give a darn".
It'll be bounced outside to be absorbed by the rest of the environment. Pretend the building isn't there - the sun is going to hit anyway, so it's not much different unless you have a convex building with a focus.
If the film is on the inside pane to prevent it from environmental damage, then there will be two passes through the outer pane, which can warm up the gas between the panes, leading ultimately to convection/conduction gain. Coating the outside would be most effective, if it weren't fragile.
Most of the heat that comes into your house will do so by conduction from the air by the window to the glass to the air by the window, then get carried around by convection. It won't get in by radiation,
Wrong. Solar gain from radiation is a significant factor in design. See for instance
this, or this, or
this, or
this.
Convection/Conduction are certainly at issue when there isn't sun (say, Seattle or Syracuse), but when there is, the radiation transmission is a major factor. This new technology sounds very promising. And yes, deciduous trees planted in good spots are a good low-tech approach.
Drat, I am really looking forward to the UAC logo swag -- T shirts, baseball hats, swiss army style knives, frisbee-like disks, bicycle jerseys.
I'd pay real money for an ersatz tour de france jersey sporting UAC primary sponsorship. Maybe nVidia and Activision could do some of it as supporting sponsors...
If this is a trend, expect a whole new artistic direction: short, concise songs that happen to clock in at exactly 1:58, 2:28 and 2:58, so as
to be "buy" slot friendly.
Yes, he's wrong on a lot of specifics, and alarmist, but the general concern of the article is something to think about: export of accumulated intangible capital which leaves how much for the exporting nations?
While there will certainly be some service/customization jobs to replace the creation of the creation of basic technology, how many will there be? We don't know.
You can make the argument that software is going to go through it's own trajectory of following the Forrest curve ,
where the cheaper (limit: free) off-the-shelf stuff is good enough, and there's no economic motivation because of low return to invest in major changes.
We have not yet seen an example of a F/OSS development that has resulted in a significant alteration of the hardware design, which requires major planning and investment. Linux has, in honesty, leeched off the PC changes driven by Microsoft and the WinHEC.
The bazaar is good for somethings; but if you think you want to build Aqueducts or Roman Roads, you may need organization more like that of the cathedral builders. The concern is that if the world is composed exlusively of folks with booths in the bazaar, how does an economy organize and fund major changes that are not small incremental steps? In absence of viable large corporations, do you result in public governmental funding and organization? That is what builds water systems, schools and highways (sometimes), if people allow themselves to be taxed.
Yes, you are the only one surprised by use of a blimp instead of a rigid airship.
Rigid airships are a lot more complicated to build structurally, since they are carrying a bunch of rigid structure that does nothing to generate lift
and can bend and break under stress. Blimps are not just one big ballon, but can and are compartmentalized for disaster containment. Blimps were built in large numbers during WWII as patrol craft, and operated in the US Navy in that role up to sometime in the 1960s. The USN gave up on rigid airships in the 30s, essentially after the Shenandoah went down in a storm.
Balloons are not blimps because they don't have maneuvering engines. A spherical blimp would have engines that move it, making it more than a balloon.
(An untethered Kite or parachute with an engine is called an ultralight, or an airplane)
One of the big issues with these proposals has been power generation and storage. The solar generators that are light enough and flexible to go on a blimp body have tended to be low efficiency compared to heavier crystal cells,
according to this, though there are claims here that new products can do nearly as well.
Batteries are notoriously heavy, so it's a tradeoff that hasn't been economically possible yet. Things need to be efficient, light, reliable, and cheap enough. The proposed HAA is still using old lead-acid batteries! I guess this works if there is enough helium, and low enough power demand (related to low wind speed to fight).
here is an article that describes this in more detail.
None of the packages I've seen for capture have anything to calibrate and shift the input chain for variable delay between sound and video encoding. It's a problem things like MythTV might profitably spend some time thinking about. Think about why there are clapboards when shooting film.
Lots of planes were going down in bad weather too. It is true there were concerns about bad designs (shenandoah, R1), but planes learned to avoid those with weather prediction.
I'm not saying airships could have survived for long-- the speed arguments along would probably have doomed them, if not the capital cost compared to a metal monoplane. I'm suggesting the PR implications may have been out of proportion to the risks, and facts about duralumin/hydrogen/helium/dope may not have had much to do with it.
Would the disaster have been as bad had the Hindenburg been filled with Helium? Would it have been consumed by fire so quickly? Is there any chance that more people could have survived?
Some people did survive. Yet it was effectively the death blow for commercial airships. So, one wonders how survivable are landing accidents of heavier-than-air vehicles? That is: was even the hydrogen accident really that much worse than the first that engulfs a plane full of fuel when it goes down? I don't know that a Hindenberg into the WTC would have burned as hot for as long as the planes did.
I just got some $17 cards from Fry's and a $32 post rebate netgear gig switch. It rocks when it works. For copying ISO images and doing backups, I'm able to get ~28mbytes/second actual throughput, which is way better than what I got with 100BT.
Unfortunately, with one linux box, the NIC doesn't work at all:-( and I haven't figured out why. When it works it's great, and the prices are cheap enough to make it viable. It just isn't quite as stable as 100 mbits is.
tcp as we know it was NOT invented in 1974 -- that was the original arpanet, before the conversion to the IPv4 internet around 1983. Dr. Rhee is closer to being correct on this point than the confused references.
Much algorithmic change has happened between the days of the 56k APRANET and multi-gigabit networks also using IP. Van Jacobsen's slow start and other ways of working out tradeoffs on bandwidth/delay vs. window size have been fiddled with for years, and arguably TCP as we know it is too compromised by history to work well as high speeds -- at least, that's what Rhee's comment suggests.
This is really relevant stuff, not to be dismissed by wannabees.
(I took it apart once before to pick out army men, and it was annoying enough to not be exciting. And there was no mechanical release on the front panel.)
Slashdot Mirror
But, for the truly pedantic (like some of us who have been involved in C coding standards for 20 years), much of the detail is interesting. I'm not sure how much general audience there would have been at $90/copy. Graduate level seminars in the ecology and natural history of language standards development?
-dB
What I fear is that this "fee" is really going to be tossed into the general fund, and no useful recycling program will be created. Then it's just a one-time TV purchase tax.
-dB
Keyhole was the most fun 3d video game I bought last year.
-dB
-dB
That was Kildall's decision, and not really subject to IBM's whim or Bill's machinations. If DR had chosen to compete on price, they could have driven the market. Trying to be the "high value justifies high cost" player in the PC market has shown itself to be a losing position, but that must not have been obvious at the time.
-dB
And MP/M-86 was a really good system for it's time, very well engineered. Not as good as a similar vintage UNIX V7, but fairly comparable to RT-11.
-dB
There is good reason to make whatever is done a 'pay as you go' rather than a lump sum. Do you want to get hit with another huge whopping tax bill when your registration is up?
The GPS scheme is DOA.
-dB
For someone on the selling side, it's more profitable to sell value-based 'solutions' rather than technology where he has to compete on price.
For someone on the buying side, getting a "solution" may be more expensive, or it may be cheaper if one doesn't want to be ones own integrator and support department. You are basically paying for reduced hassle. The trick is quantifying the value of your own hassle, and the liklihood the 'solution' will have its own hassles, and their cost. Different people will evalutate these things differently.
-dB
So do I, but there seems to be darned little of it in the software that I see.
-dB
Being from a top-N school will open doors for your first job, and you may be better networked in school and for a while afterwards to opportunities. You may have better opportunity to try something that gets noticed to form your own startup (eg: Google). A lot of this depends on whether you stay for an MSCS as well.
If you are learning plenty now, and planning on grad school, you might stay where you are and target a top-N school as the next step. If you don't plan on grad school, and don't have a calling card project on which to hang your hat, a prestige school won't hurt. Joe Schlemiel from Podunk Extension isn't going to get much attention from many employers outside Podunk.
-dB
Here is a link: TINY_C.ZIP
And to a book about it: Learning C with tiny c
I learned a lot from this package in 1980, even though I never had an 8080 to run it on. I hand coded it in assembler to run on Interdata machines instead. Still have the loose-leaf in the garage as a prized memento.
The other was a byte-code compiler for a slightly more expansive language. This ran faster, but I never bought it to see.
-dB
This is fixed by defining __TINYC__ in the rule for bcheck.o, and you get a tcc executable. Trying to remake it with itself
Results in complaints about stddef.h not found. Adding -I/usr/include/linux leaves us with other errors, and as Mr. Costello would say at this point, "I don't give a darn".My interest just ran dry for now.
-dB, on third base.
If the film is on the inside pane to prevent it from environmental damage, then there will be two passes through the outer pane, which can warm up the gas between the panes, leading ultimately to convection/conduction gain. Coating the outside would be most effective, if it weren't fragile.
-dB
Wrong. Solar gain from radiation is a significant factor in design. See for instance this, or this, or this, or this.
Convection/Conduction are certainly at issue when there isn't sun (say, Seattle or Syracuse), but when there is, the radiation transmission is a major factor. This new technology sounds very promising. And yes, deciduous trees planted in good spots are a good low-tech approach.
-dB
I'd pay real money for an ersatz tour de france jersey sporting UAC primary sponsorship. Maybe nVidia and Activision could do some of it as supporting sponsors...
-dB
-dB
While there will certainly be some service/customization jobs to replace the creation of the creation of basic technology, how many will there be? We don't know.
You can make the argument that software is going to go through it's own trajectory of following the Forrest curve , where the cheaper (limit: free) off-the-shelf stuff is good enough, and there's no economic motivation because of low return to invest in major changes.
We have not yet seen an example of a F/OSS development that has resulted in a significant alteration of the hardware design, which requires major planning and investment. Linux has, in honesty, leeched off the PC changes driven by Microsoft and the WinHEC.
The bazaar is good for somethings; but if you think you want to build Aqueducts or Roman Roads, you may need organization more like that of the cathedral builders. The concern is that if the world is composed exlusively of folks with booths in the bazaar, how does an economy organize and fund major changes that are not small incremental steps? In absence of viable large corporations, do you result in public governmental funding and organization? That is what builds water systems, schools and highways (sometimes), if people allow themselves to be taxed.
-dB
Rigid airships are a lot more complicated to build structurally, since they are carrying a bunch of rigid structure that does nothing to generate lift and can bend and break under stress. Blimps are not just one big ballon, but can and are compartmentalized for disaster containment. Blimps were built in large numbers during WWII as patrol craft, and operated in the US Navy in that role up to sometime in the 1960s. The USN gave up on rigid airships in the 30s, essentially after the Shenandoah went down in a storm.
Balloons are not blimps because they don't have maneuvering engines. A spherical blimp would have engines that move it, making it more than a balloon.
(An untethered Kite or parachute with an engine is called an ultralight, or an airplane)
One of the big issues with these proposals has been power generation and storage. The solar generators that are light enough and flexible to go on a blimp body have tended to be low efficiency compared to heavier crystal cells, according to this, though there are claims here that new products can do nearly as well.
Batteries are notoriously heavy, so it's a tradeoff that hasn't been economically possible yet. Things need to be efficient, light, reliable, and cheap enough. The proposed HAA is still using old lead-acid batteries! I guess this works if there is enough helium, and low enough power demand (related to low wind speed to fight).
here is an article that describes this in more detail.
-dB
-dB
you, sir, are a loony.
I'm not saying airships could have survived for long-- the speed arguments along would probably have doomed them, if not the capital cost compared to a metal monoplane. I'm suggesting the PR implications may have been out of proportion to the risks, and facts about duralumin/hydrogen/helium/dope may not have had much to do with it.
-dB
Some people did survive. Yet it was effectively the death blow for commercial airships. So, one wonders how survivable are landing accidents of heavier-than-air vehicles? That is: was even the hydrogen accident really that much worse than the first that engulfs a plane full of fuel when it goes down? I don't know that a Hindenberg into the WTC would have burned as hot for as long as the planes did.
-dB
Unfortunately, with one linux box, the NIC doesn't work at all :-( and I haven't figured out why. When it works it's great, and the prices are cheap enough to make it viable. It just isn't quite as stable as 100 mbits is.
-dB
Much algorithmic change has happened between the days of the 56k APRANET and multi-gigabit networks also using IP. Van Jacobsen's slow start and other ways of working out tradeoffs on bandwidth/delay vs. window size have been fiddled with for years, and arguably TCP as we know it is too compromised by history to work well as high speeds -- at least, that's what Rhee's comment suggests.
This is really relevant stuff, not to be dismissed by wannabees.
-dB
(I took it apart once before to pick out army men, and it was annoying enough to not be exciting. And there was no mechanical release on the front panel.)
-dB