you know you're shooting with 400 speed film. throw a polaroid back with 400 speed polaroid film on your medium or large format camera, and _with the same lighting and exposure settings_ take a polaroid shot. it develops in a minute or so, and you can see if you need to adjust, how your shadows are coming out, if your framing and composition is OK, etc.
it's like a very slow LCD back.
I don't follow how BSD will be affected by GPLv3.
neither NetBSD, FreeBSD, and OpenBSD use the GNU C library.
code generated by gcc isn't covered under the GPL.
See, this is exactly what I am talking about. People who THINK they know how electronics work but clearly have not actually worked with the raw components on a bench before.
you quite obviously never have worked with digital audio at the component level on a bench before, as you are completely ignoring antialias filtering, both on the ADC and DAC. take those "straight lines" you get from a bandwidth-limited ADC, run them back through a DAC with the same bandwidth limitation, and you get your signals back out. it's not magic. it's antialias filtering.
The ADC samples the voltage and outputs that value as binary information, correct? So, explain to me how you can reproduce a smooth sinewave with two voltage samples? Because you cannot, if you plot the data that is actually available from the ADC you will get straight lines, something between a triangle wave and a square wave.
you need just over two samples. a small fraction more than two samples is sufficient. (yes, a fraction of a sample.)
The 68000 line could have been developed further; there was nothing in the architecture that limited it. But when Apple dropped it, that was the end of the demand for high-end 68000 parts.
the 68k line was developed further in the coldfire line, the first (internal) version of which was based around a microcoded 68060 core. (email me; I have the original whitepaper sitting around somewhere.) motorola/freescale wised up and re-implemented the idea in verilog as opposed to the hand-layed optical masks used for the 060 and previous models, and the v2 coldfire was born. (the v1 has since been back-filled.)
I wonder if apple's movement from motorola to PPC-land spurred development of coldfire, or if apple was just a drop in the bucket to motorola. (perhaps much like freescale's indifference to apple's movement from PPC to intel?)
FWIW, our website is being served up using the same board as in the toaster. Apache is configured for 30 simultaneous connections (which all are full) and the load average is 0.3 and the system remains very responsive via ssh. As we had suspected, we're limited 100% by bandwidth and not by NetBSD or the TS-7200 board.
now to get NetBSD/coffeemaker going. I knew that MRKRUPS kernel config was there for a reason...
The 680x0 was not a growable architecture; the PPC architecture was (and still is).
actually... motorola^Wfreescale dusted off the 68k dead horse, stripped down the opcode set, implemented it in a synthesizable RISC core, and out popped coldfire.
for embedded work it's still nice to beat on, but unfortunately gcc support is still all over the place, although the situation has been improving recently.
sure, you can use PWM to do digital output through a PC speaker, but it eats a lot of system resources to do so. demoscene hackers were enthralled when the gravis ultrasound card came out since it let you offload all the mixing and resampling out to hardware. Of course with CPU power getting so cheap these days, sound cards seem to be getting lower-tech as more things which used to be handled in hardware are done in software.
NetBSD 1.6.1 still ships with Taylor UUCP which is still GNU. I'm sure a BSD-licensed HoneyDanBer version could be probably be pulled out of the woodwork without much hassle, though.
perhaps one day the BSD licensed TenDRA compiler could be used to compile NetBSD...
Re:ARM ADS, dedicated MP3 chips, and bus power
on
New MP3 Portables
·
· Score: 1
Actually, the big problem is that the iPod player runs audio through a chip that takes MP3 audio on one pin and produces PCM audio on another. It's much harder to change hardware than software.
this is not the case with the iPod, which is based around a dual ARM system. all decoding is performed in software running on one of the ARMs. according to my friend / mole at PortalPlayer (which did the reference design the iPod is based on) the only reason OGG hasn't been added is that there has been little to no customer demand. there aren't any good technical reasons.
if you want OGG on your iPod, pester apple silly, who in turn will pester portalplayer to do the support.
OpenBSD's other strength is that it is rapidly gaining on NetBSD where being able to run on many different hardware platforms is concerned.
Considering OpenBSD and NetBSD are closely related, there's plenty of cross-pollination between the two. NetBSD may have hpcmips, but OpenBSD has mvme88k. it really is a shame both sides couldn't come to some kind of agreement and make up for past behavior, but until then, the CVS trees on both sides are world-readable.:)
NetBSD will run on almost any 16+ bit computer you can find.
NetBSD needs at least 32 bits and an MMU.
a point I haven't seen brought up is that putting IRIX compatibility into NetBSD/sgimips carries over to other big-endian MIPS ports as well. granted there aren't a lot of these still in production aside from a few evaluation boards, but at least the option is there.
Honest to god, with vintage hardware, if it doesn't have the mouse and keyboard, and every other proprietary piece, you're better off waiting.
even if you can't get ahold of (semi-) proprietary peripherals, these are "real machines" after all, and can be run from a serial port. I've got a stack of SGI challenge Ss in my basement that run this way.
My DECstation is still wanting the puck mouse and a copy of Ultrix 4.3
if you don't dig ultrix, (or can't get it,) NetBSD has been running on DECStations now for years. my main machine (DNS, HTTP, SMTP, SSH plus a handful of users) at home is a 5000/240 running NetBSD 1.4.3A and I have nothing but praise for its reliability. the hardware is easily capable of five-nines uptime and is very well engineered. even the smaller 2100s and 3100s can make reliable light servers.
And please. Don't ever butcher vintage hardware. [...]this really does make me sad.
The horror!:~( to think that perfectly functional machines still capable of useful work are getting destroyed and scrapped around the world everyday is bad enough, but if people start scrapping machines to cool cases? no respect.
If Darren Reed hadn't been such a stubborn cock and lightened up on his licensing then perhaps ipf would still be part of the OpenBSD install.
s/Darren Reed/Theo de Raadt/
a little courtesy on both sides could've gone a long way. Theo truly brings out the best and worst in people.
Re:Do you care about your kernel?
on
Debian NetBSD
·
· Score: 1
there is support in -current for SMP on i386, VAX, and alpha. (links are to old posts in tech-kern.) work is in progress for sparc, mips, and maybe a few others. (m68k?)
one of the goals is to get SMP branches merged back into the trunk for 1.6.
Slashdot Mirror
starcon 2 used 4-channel amiga-style mods.
you know you're shooting with 400 speed film. throw a polaroid back with 400 speed polaroid film on your medium or large format camera, and _with the same lighting and exposure settings_ take a polaroid shot. it develops in a minute or so, and you can see if you need to adjust, how your shadows are coming out, if your framing and composition is OK, etc. it's like a very slow LCD back.
you've obviously never used the whitbread (wyeast 1099) or Fuller's ESB (wyeast 1968) strains. both are incredibly flocculant.
I don't follow how BSD will be affected by GPLv3. neither NetBSD, FreeBSD, and OpenBSD use the GNU C library. code generated by gcc isn't covered under the GPL.
someone remind me again what language Unix was written in?
the 68k line was developed further in the coldfire line, the first (internal) version of which was based around a microcoded 68060 core. (email me; I have the original whitepaper sitting around somewhere.) motorola/freescale wised up and re-implemented the idea in verilog as opposed to the hand-layed optical masks used for the 060 and previous models, and the v2 coldfire was born. (the v1 has since been back-filled.)
I wonder if apple's movement from motorola to PPC-land spurred development of coldfire, or if apple was just a drop in the bucket to motorola. (perhaps much like freescale's indifference to apple's movement from PPC to intel?)
actually... motorola^Wfreescale dusted off the 68k dead horse, stripped down the opcode set, implemented it in a synthesizable RISC core, and out popped coldfire. for embedded work it's still nice to beat on, but unfortunately gcc support is still all over the place, although the situation has been improving recently.
Bin Laden
I personally have had good luck with both as far as attenuation goes, but the custom molds are much more comfortable for long periods of time.
sure, you can use PWM to do digital output through a PC speaker, but it eats a lot of system resources to do so. demoscene hackers were enthralled when the gravis ultrasound card came out since it let you offload all the mixing and resampling out to hardware. Of course with CPU power getting so cheap these days, sound cards seem to be getting lower-tech as more things which used to be handled in hardware are done in software.
I liked iolo's little song.
Now electronic news is reporting that St. Dennis was ousted by the board.
NetBSD 1.6.1 still ships with Taylor UUCP which is still GNU. I'm sure a BSD-licensed HoneyDanBer version could be probably be pulled out of the woodwork without much hassle, though.
perhaps one day the BSD licensed TenDRA compiler could be used to compile NetBSD...
this is not the case with the iPod, which is based around a dual ARM system. all decoding is performed in software running on one of the ARMs. according to my friend / mole at PortalPlayer (which did the reference design the iPod is based on) the only reason OGG hasn't been added is that there has been little to no customer demand. there aren't any good technical reasons.
if you want OGG on your iPod, pester apple silly, who in turn will pester portalplayer to do the support.
Considering OpenBSD and NetBSD are closely related, there's plenty of cross-pollination between the two. NetBSD may have hpcmips, but OpenBSD has mvme88k. it really is a shame both sides couldn't come to some kind of agreement and make up for past behavior, but until then, the CVS trees on both sides are world-readable. :)
Where else can one get a cheap a evaluation system for the super hitachi processor? official eval boards aren't cheap.
NetBSD needs at least 32 bits and an MMU.
a point I haven't seen brought up is that putting IRIX compatibility into NetBSD/sgimips carries over to other big-endian MIPS ports as well. granted there aren't a lot of these still in production aside from a few evaluation boards, but at least the option is there.
I asked this question of SGI. they were willing to sell me new copies of IRIX -- at $600 per machine. I think I'll stick with NetBSD.
GRUB has support on i386 for booting NetBSD kernels directly, or at least that's what the GRUB documentation claims.
even if you can't get ahold of (semi-) proprietary peripherals, these are "real machines" after all, and can be run from a serial port. I've got a stack of SGI challenge Ss in my basement that run this way.
if you don't dig ultrix, (or can't get it,) NetBSD has been running on DECStations now for years. my main machine (DNS, HTTP, SMTP, SSH plus a handful of users) at home is a 5000/240 running NetBSD 1.4.3A and I have nothing but praise for its reliability. the hardware is easily capable of five-nines uptime and is very well engineered. even the smaller 2100s and 3100s can make reliable light servers.
The horror! :~( to think that perfectly functional machines still capable of useful work are getting destroyed and scrapped around the world everyday is bad enough, but if people start scrapping machines to cool cases? no respect.
visit thepoofygoof orphanarium for obsolete unix boxes
s/Darren Reed/Theo de Raadt/
a little courtesy on both sides could've gone a long way. Theo truly brings out the best and worst in people.
there is support in -current for SMP on i386, VAX, and alpha. (links are to old posts in tech-kern.) work is in progress for sparc, mips, and maybe a few others. (m68k?)
one of the goals is to get SMP branches merged back into the trunk for 1.6.