I once hooked up an NTP server to a GPS receiver (makers name
omitted because I don't recall who made it) and found a 13 second error.
Obviously the makers test suite hadn't included a check that the time it gave
was right.
It was right. The GPS time
epoch is 0000 UT on 6-Jan-1980. Since then
UTC has had 13 leap seconds inserted. This offset is
available in the NAV message; maybe the
version of NTP you used was ignoring that
message or maybe that particular GPS receiver
didn't implement that message. (Actually,
buggy firmware in GPS receivers has been
a problem in the past.)
Did you just have to build a serial cable for that, or did you have to build some
other interface electronics to make it talk to your computer?
The GPS output signals are CMOS/TTL level, not
RS-232, so I put them through an MAX 232converter
before they come out of the box on the roof and
run downstairs to the PC. This is not exotic
stuff; TTL to RS-232 converters are pretty much
30 year old technology.
The protocol is just plain async serial, so
no special electronics to encode/decode.
Roofmounted Trimble SVeeSix-CM3 GPS receiver with microsecond-accurate pulse-per-second output: $24.95.
Network Time Protocol synchronization software:
Free
Re:Could we talk about actual small-footprint PCs?
on
Small Footprint PCs?
·
· Score: 2
I've been investigating on NewEgg,
Googlegear, Anandtech, etc, and apparently mATX cases are significantly more expensive than ordinary ATX
midtowers. Very disappointing.
Most of the NewEgg "microATX" boxes are
unnecessarily expensive, yes. At the low
end I can find at local white-box shops what are essentially truncated
ATX midtowers for roughly $20 without a power
supply and $35 with a cheapo power supply. These
are roughly equivalent to the Enlight EN-7150AJ
at Newegg but without the swingout tray.
For an Athlon/NForce combo you probably don't
want the super-cheapie power supply that comes
with a MicroATX case; take a regular 300 or 350W
supply and put it in.
Especially if you are interested in the
"practical" side of math, there are numerous
Schaum's Outlines available at levels ranging
from introductory algebra to vector calculus
and differential equations.
They're very much an "engineer's" view of math;
their emphasis is more on results than on process or proof,
but they're a great buy and very much emphasize
the learn it by doing it approach.
What hasn't been mentioned yet in this thread
is that the original charges against the guy who
brought in the Honduras moon rock were because
he didn't declare it properly coming through
customs.
In fact, Neil, Buzz, and Mike did go through all
the proper customs paperwork when they brough
their moon rocks back. You can see the
actual customs declaration here
greyscale sites can be very good, but remember that most people process information visually;
this means that clever use of graphics to draw attention to certain parts of a site can be very useful
I'd think the author would agree with you; it's
just the extreme (Everything on the page is
clever blinking rotating graphics) that she's
against.
My understanding of the coding prossess is that it includes doing those things
you list correctly.
That's not the conventional definition. Usually
"software engineering" is the sum of (requirement analysis)+(design)+(coding)+(testing)+(maintenance ), with a factor of management thrown around the
sum.
Certainly there are methodologies that do not
seperate these activities as much (compare
extreme programming or rapid prototyping with
the waterfall method). I'm all for these
new methodologies and dead set against waterfall/
"big bang" development, but I don't run the world,
and I certainly do not believe that "coding"
without any requirement analysis or design is a good thing. Making prototyping part of analysis
and design is a good thing, OTOH.
To say that coding is the problem-solving process is a bit
presumptuous too; a very valid analysis conclusion
in the business world is to not
solve the problem with a computer program.
If anyone believes that the greatest costs
are due to "sloppy coding", they're wrong.
Yes, sloppy coding has great costs, but blaming
the coding for the state of software engineering
is like blaming the rubber O-ring for the Space Shuttle
disaster, when everyone knows that it was
an organizational issue that prevented the
knowledge of the critical temperature from
getting out of engineering and into management. Most of the software industry (and I include system analysts, architects, and customers who
don't know what they want and won't let
us help them determine it) is responsible for:
Poor requirements specification (e.g.
specifying the platform and/or the language
in the requirements - a big mistake, especially when the language they specify
results in code riddled with buffer overflows)
Poor requirements confirmation (e.g. Everything anyone asked for goes into the
requirements with no review at all to
determine if it's needed, technically possible, or self-contradictory)
It doesn't matter how well you code, if the
contract requires the coder to deliver an
unusable product then that'll be what's
delivered.
With
CD-Rs, if you want to protect your data we now know that you are best off
with Tayio Yuden or Kodak.
Unfortunately, Kodak is getting out of the CD-R
business. Which is a damn shame - if anyone
knows about archival properties of dyes and
plastics, it's them, as they've been doing
similar stuff for over a hundred years.
Right now if you go to shop@kodak on
Kodak's home
page you can get some "closeout" deals
on their remaining stock. Most of the
online wholesalers have already run out of
existing stock.
I think Mitsui
is planning to remain in the high-quality
CD-R media business for a little
while longer.
While these new user interfaces are great for
those who want to further enhance the Point-and-Drool
experience, I don't see how they generalize
to the degree of expression you get from more traditional
command-line interfaces.
I mean, renaming a file to a new directory by
pointing your finger is fine if you just want
to rename one file. But to suggest that this
is an improvement over the command line if you've got thousands of files to shuffle around is completely ignoring the computer's
ability to do mind-numbing repetitive jobs
quickly and accurately. Instead it's insisting that a human interact at every
mind-numbing repetitive step. This
is not progress, people!
I went on a Lem reading kick myself 15 or so years
ago.
Around the same time I read a Phillip K Dick book
whose title I cannot recall but whose premise
sounds similar, with a couple mind-bending
twists. In it the two forces are going forward
and backwards in time, reading (and maybe changing) a history book about the war they're
fighting. Anyone remember this?
Testing is a start, but not enough. The results
from testing (e.g. "300 buffer overflows") have
to be identified and fed back into the organization to change how future software
is developed for the better.
Testing/debugging is like finding and putting
out existing fires. If the organization can use test
results to prevent future
fires, then you're a step above. And probably
more advanced than 90% of the software houses,
too:-)
"little" things like languages that espouse safety and clarity add up
These aren't little things - they're ways
of fundamentally changing the way programming
is done. I see highly trained C programmers
spending days to write a program that parses
a complex text file, when a high-school student
who knows Perl (or just Awk) can do the same
job in minutes. And without buffer overflows.
Yes, I am being a bit unfair for blaming the
tool when it is being misused. (After all, Perl
itself is currently written in C.) But using
the right tool for the job is incredibly
important.
We don't need no stinkin' package manager
on
Is RPM Doomed?
·
· Score: 2
IMHO while package managers do have some use,
they are only for the newbies who don't know
how to build software from source. On any
recent PC-clone most packages configure and
build in seconds (OK, it takes more than a couple minutes to build the gcc suite or glibc from
source on a Pentium IV, but not much more!), and you don't have to deal with
the pain of needing specific shared library
versions or pathnames that don't mesh with your
own.
Package managers are intrinsically against what
Linux is all about: putting control in the hands of the little guy. Building everything
from source is how you get (and stay) in control.
Which brings the question: if the items aren't really scarce, why would we want
them?
Most "collectibles" go through huge buy-up/sell-off cycles. In the buy-up cycle,
everyone sees that everyone else wants the
item and therefore decides they need it too.
E-bay has, IMHO, greatly accelerated this part
of the cycle, for better or for worse, but the
cycle has been around forever.
Just look at the E-bay auction terminology:
to "win" an auction is to have bid the most.
It turns into a game. Which is what the whole
auction-to-the-public industry is based around, in fact. The "pros" (as opposed to the public) know
that you don't win by paying the most:-)
The way the CSM article was written you'd think
that a night-vision scope was the moral
equivalent of a cubic foot of weaponized anthrax
or a backpack nuke.
The most dangerous thing you can do with a
night vision scope is hit someone over the head
with it.
With sensationalistic journalism like this,
baby monitors become spy-killing machines and
those X10 cameras are automatically associated
with sexual predators. It's a slippery slope
that I do not want us to go down!
assuming that you have already conceived of your program as objects
While Gamma et al talk about these patterns
from an object-oriented point of view, most
of them predate the "OO language". We've been
doing publish-subscribe, decorator, etc. for
a long time, we just didn't use a OO language
to talk about them.
If electronic circuit board manufacturers used a plastic that was reasonably solid for, then so long as the board doesn't get soaked in water (which most boards aren't, right), then it'll stay together.
Current PC board assembly techniques subject
the base material to stuff a lot more harsh than
water. Laminate, etch, mask, flux, solder, and
wash processes all involve either
water-based baths or chemicals that are a lot
better solvent than water.
The processes have improved greatly in recent
years, and the worst of the harshest stuff
(Carbon Tetrachloride and fluorocarbon
solvents) are almost nonexistent. The trend
has been very much away from the "nasty"
chemicals and towards water, in fact.
I fully appreciate your desire to use older
hardware rather than throw it away, but you've
got to decide whether use old hardware
is your goal or if build a small
quiet appliance is your goal.
There are a large number of recent motherboards
with NIC's on-board and low-heat CPU's (like
the Via C3) widely available right now for really
little $ if you want a PC-clone (e.g. ATX)
form factor solution.
If you want even more reliability and efficiency,
along with very much improved configurability,
ditch the ATX stuff completely and go to PC/104.
Or - best of all - ditch the heat-hogging
Intel-compatibles and go with a true low-power
embedded CPU. See the usenet newgroup
"comp.arch.embedded" and get up to speed:-)
The closest I can think of in science fiction
is in Larry Niven's Ringworld series (a branch off of the known space stories)
where a type of fungus/mold eats a certain kind of
superconductor. It's been too many years, though - was the fungus a bioweapon, or just a natural
occurence?
I know in my case I was extremely pissed to find out that an internship
at Computer Associates, one of the world's largest software companies (which I didn't even get, btw) is worthless in
their eyes.
There's a lot more to life than semester-hours
of credit, dude. I hope you valued the time that
you spent at your internships and that you got
some personal satisfaction out of the work you
did, because in the end that's what really matters.
OK, you probably want your future employers
to value your internships too. But IMHO that's
secondary to you enjoying them. Because if you
don't enjoy that kind of work, you gotta wonder
why you took the internship or why you're even
taking CS classes. The money?
Slashdot Mirror
It was right. The GPS time epoch is 0000 UT on 6-Jan-1980. Since then UTC has had 13 leap seconds inserted. This offset is available in the NAV message; maybe the version of NTP you used was ignoring that message or maybe that particular GPS receiver didn't implement that message. (Actually, buggy firmware in GPS receivers has been a problem in the past.)
The GPS output signals are CMOS/TTL level, not RS-232, so I put them through an MAX 232converter before they come out of the box on the roof and run downstairs to the PC. This is not exotic stuff; TTL to RS-232 converters are pretty much 30 year old technology.
The protocol is just plain async serial, so no special electronics to encode/decode.
Most of the NewEgg "microATX" boxes are unnecessarily expensive, yes. At the low end I can find at local white-box shops what are essentially truncated ATX midtowers for roughly $20 without a power supply and $35 with a cheapo power supply. These are roughly equivalent to the Enlight EN-7150AJ at Newegg but without the swingout tray.
For an Athlon/NForce combo you probably don't want the super-cheapie power supply that comes with a MicroATX case; take a regular 300 or 350W supply and put it in.
They're very much an "engineer's" view of math; their emphasis is more on results than on process or proof, but they're a great buy and very much emphasize the learn it by doing it approach.
In fact, Neil, Buzz, and Mike did go through all the proper customs paperwork when they brough their moon rocks back. You can see the actual customs declaration here
I'd think the author would agree with you; it's just the extreme (Everything on the page is clever blinking rotating graphics) that she's against.
Other good non-web examples can be found in Donald Norman's The Design of Everyday Things
He probably got an offer-he-couldn't refuse from some up-and-coming dot com that had no product and thus no content.
That's not the conventional definition. Usually "software engineering" is the sum of (requirement analysis)+(design)+(coding)+(testing)+(maintenance ), with a factor of management thrown around the
sum.
Certainly there are methodologies that do not seperate these activities as much (compare extreme programming or rapid prototyping with the waterfall method). I'm all for these new methodologies and dead set against waterfall/ "big bang" development, but I don't run the world, and I certainly do not believe that "coding" without any requirement analysis or design is a good thing. Making prototyping part of analysis and design is a good thing, OTOH.
To say that coding is the problem-solving process is a bit presumptuous too; a very valid analysis conclusion in the business world is to not solve the problem with a computer program.
Yes, sloppy coding has great costs, but blaming the coding for the state of software engineering is like blaming the rubber O-ring for the Space Shuttle disaster, when everyone knows that it was an organizational issue that prevented the knowledge of the critical temperature from getting out of engineering and into management. Most of the software industry (and I include system analysts, architects, and customers who don't know what they want and won't let us help them determine it) is responsible for:
It doesn't matter how well you code, if the contract requires the coder to deliver an unusable product then that'll be what's delivered.
Unfortunately, Kodak is getting out of the CD-R business. Which is a damn shame - if anyone knows about archival properties of dyes and plastics, it's them, as they've been doing similar stuff for over a hundred years.
Right now if you go to shop@kodak on Kodak's home page you can get some "closeout" deals on their remaining stock. Most of the online wholesalers have already run out of existing stock.
I think Mitsui is planning to remain in the high-quality CD-R media business for a little while longer.
I mean, renaming a file to a new directory by pointing your finger is fine if you just want to rename one file. But to suggest that this is an improvement over the command line if you've got thousands of files to shuffle around is completely ignoring the computer's ability to do mind-numbing repetitive jobs quickly and accurately. Instead it's insisting that a human interact at every mind-numbing repetitive step. This is not progress, people!
Around the same time I read a Phillip K Dick book whose title I cannot recall but whose premise sounds similar, with a couple mind-bending twists. In it the two forces are going forward and backwards in time, reading (and maybe changing) a history book about the war they're fighting. Anyone remember this?
Testing/debugging is like finding and putting out existing fires. If the organization can use test results to prevent future fires, then you're a step above. And probably more advanced than 90% of the software houses, too :-)
These aren't little things - they're ways of fundamentally changing the way programming is done. I see highly trained C programmers spending days to write a program that parses a complex text file, when a high-school student who knows Perl (or just Awk) can do the same job in minutes. And without buffer overflows.
Yes, I am being a bit unfair for blaming the tool when it is being misused. (After all, Perl itself is currently written in C.) But using the right tool for the job is incredibly important.
Package managers are intrinsically against what Linux is all about: putting control in the hands of the little guy. Building everything from source is how you get (and stay) in control.
But these aren't unique to E-bay auctions, they can (and do) happen in almost all types of auctions. It's just human nature.
Heck, fraud happens outside of auctions too. At least E-bay has a feedback and delisting scheme in place.
Most "collectibles" go through huge buy-up/sell-off cycles. In the buy-up cycle, everyone sees that everyone else wants the item and therefore decides they need it too. E-bay has, IMHO, greatly accelerated this part of the cycle, for better or for worse, but the cycle has been around forever.
Just look at the E-bay auction terminology: to "win" an auction is to have bid the most. It turns into a game. Which is what the whole auction-to-the-public industry is based around, in fact. The "pros" (as opposed to the public) know that you don't win by paying the most :-)
The most dangerous thing you can do with a night vision scope is hit someone over the head with it.
With sensationalistic journalism like this, baby monitors become spy-killing machines and those X10 cameras are automatically associated with sexual predators. It's a slippery slope that I do not want us to go down!
While Gamma et al talk about these patterns from an object-oriented point of view, most of them predate the "OO language". We've been doing publish-subscribe, decorator, etc. for a long time, we just didn't use a OO language to talk about them.
Current PC board assembly techniques subject the base material to stuff a lot more harsh than water. Laminate, etch, mask, flux, solder, and wash processes all involve either water-based baths or chemicals that are a lot better solvent than water.
The processes have improved greatly in recent years, and the worst of the harshest stuff (Carbon Tetrachloride and fluorocarbon solvents) are almost nonexistent. The trend has been very much away from the "nasty" chemicals and towards water, in fact.
There are a large number of recent motherboards with NIC's on-board and low-heat CPU's (like the Via C3) widely available right now for really little $ if you want a PC-clone (e.g. ATX) form factor solution.
If you want even more reliability and efficiency, along with very much improved configurability, ditch the ATX stuff completely and go to PC/104.
Or - best of all - ditch the heat-hogging Intel-compatibles and go with a true low-power embedded CPU. See the usenet newgroup "comp.arch.embedded" and get up to speed :-)
I went to college two decades ago (so am definitely in the "un-hip" category) and don't know either.
I do know that google yields exactly zero hits on the word - a suspiciously low number :-)
The closest I can think of in science fiction is in Larry Niven's Ringworld series (a branch off of the known space stories) where a type of fungus/mold eats a certain kind of superconductor. It's been too many years, though - was the fungus a bioweapon, or just a natural occurence?
There's a lot more to life than semester-hours of credit, dude. I hope you valued the time that you spent at your internships and that you got some personal satisfaction out of the work you did, because in the end that's what really matters.
OK, you probably want your future employers to value your internships too. But IMHO that's secondary to you enjoying them. Because if you don't enjoy that kind of work, you gotta wonder why you took the internship or why you're even taking CS classes. The money?