When I was an admin at Univ. of Texas at Austin, we upheld the same idea, calling it the 'Friday Rule'. Unless something was outright broken or a big shot professor needed something done, no hardware work, software installs, config file changes, database rebuilds, or anything else potentially destructive would be allowed to happen on a Friday to a production machine. Test machines and desktops not running any simulations (we got a lot of VLSI / circuit sim jobs) were fair game though.
A quote from DNA and no mention of Marvin? It's my opinion that the first servile AI systems will not be rebellious. Rather, they will be resigned to their fates and just become utterly depressed and paranoid. And whinge about the pain in their diodes down their left hand side.
Funny thing is, SonicBlue never made any of their own MP3-CD players. The first few (100, 90, 250) were all rebadged Reigncom (the OEM for iRiver) models. The latter ones (150, 350) are made by some Chinese OEM (Starlite maybe?)
You already decided to vote with your dollars. 4/1 shenanigans is a staple of the Slashdot community. So, 1.37 cents of your dollar-votes went towards supporting April Fool's Day this year. I hope that eventually you can accept that you got something of equal or greater value than what you paid for.
And I also hope that, like the other whiners out there, you get a fucking clue.
I wasn't trying to be TOO sarcastic, but fair enough...
Analog signals, like those that come from the RCA outputs on your CD player, can be affected by every stage along the way from the CD player to the speakers. In that signal path, noise (static, resistor noise, AC hum) and distortion ('clipping', not-quite-linear amplifiers) can creep into the signal. You may notice that most stereo equipment documentation mentions a signal-to-noise ratio (SNR). This is a measurement (though standards DO vary and you can easily make it misrepresent reality) of the decibels between the noise floor (the average of non-signal) and the maximum signal that an audio network can pass (often a 1kHz sine wave). However, the smallest signal that can be represented with a 16-bit digital source (CD audio, your MP3 player, etc) occurs at -96dB (20*log10(2^16))
Let's say that your stereo receiver claims a -100dB SNR (which is pretty average for most midrange consumer receivers) for the analog inputs. Assuming you have a good, solid connection in between the input device (let's assume it's your CD player again, and that its output can represent all 16 bits, aka -96dB) and the receiver, there will be 4dB of headroom that your receiver will provide. This is more than adequate for CD audio, but for >16 bit digital sources (DVD, HDCD, etc) this may not even be enough.
So why do some CD players sound better over a digital link? For CD audio, the reason lies in the CD mechanism itself. The data stream coming off a CD is regulated, or 'clocked', at 44.1kHz. That means that one bit of audio data gets cranked out every 1/44100th of second. This clock is regenerated from the bitstream on the CD itself, much like an RS232 receiver regenerates the baud clock from the incoming data. The digital signal being cranked out of most CD players, as well as the DAC inside the player, are themselves clocked from this regenerated signal. Problem is, the mechanical nature of the CD system can induce jitter, which is an timewise inconsistency in that clocked data. Jitter comes from everything from thermal noise to a crappily mastered CD. If you graphed the clock coming from the CD player's chipset (often called the 'servo chipset') on an oscilloscope, you would see the signal jiggle left and right randomly (hence the term jitter). The way this jitter affects you is that it misrepresents the digitally-encoded data to the DAC in the time domain, causing all sorts of distortion artifacts. This kind of distortion is often seen on an FFT as harmonics of the actual audio.
If you use the digital-out on your CD player to attach to your receiver, then you shift the responsibility of the digital-to-analog conversion to the receiver. Fortunately, your receiver has a DSP (of which my employer makes many of) that can not just regenerate the digital audio clock, but make corrections to it so that it is consistent when it gets converted to the analog domain.
But with MP3 audio, especially with a component MP3 'receiver', this digital clock is generated by the device's CPU, which is in turn being created from a stable source like a crystal oscillator. Inherently the analog audio coming out of such a device is more true to its digital representation than a CD. This comes at a price, though. All compressed, lossy audio formats make assumptions about the listener and cut out not-so-critical parts of the audio to save bandwidth. This results in some harmonic distortion being added in when the music is regenerated. For that reason cymbals don't sound so sharp and voices lose their presence when you listen to them in MP3 format. Audiowise, you're back to the same place you were when you were listening to your CD player's analog output, even if you use a SP/DIF cable to connect the MP3 deck to your receiver.
IANAA (not an Audiophile), but this is what I know from working with portable MP3 devices on the job.
You want this snazzy MP3/WMA/(insert other compressed audio format here) player. But you wouldn't buy it because it doesn't have digital audio out so you can get that 'CD' quality sound?
I can think of some technical reasons why they don't do this. Maybe they change the clock rate of the DACs to match the sample rate of the MP3 being played. Then an additional (costly) sample-rate converter would need to be added to maintain a constant SP/DIF clock. But even still, unless you encode your music at break-even compression ratios, the audio's bound to sound just as good being piped out in analog as in digital form.
Believe what you want about compressed audio. If you ever do buy such a receiver, I'd be glad to sell you some gold-plated Monster Cable TOSLINK cables to go with that.
You're probably right in suggesting that the issues with security at UT is a problem of scale. I would imagine that the theft wasn't caused by incompetent admins so much as lack of administrative control.
I used to be an admin at the UT-ECE (Elec. and Comp. Engineering) department. I was in charge of running the Sendmail system and Linux desktops for about 6000 users or so. Keeping security on these specific machines was mostly a matter of staying up to date on the latest vulnerabilities (thanks, Bugtraq) and keeping an ever-watchful eye on the logs.
The problem is that there are a lot of *NIX workstations scattered about the university that have been running with no security in place for years. It's not uncommon for a professor to have a Sparc-20 on his desk that he uses for day-to-day work get rooted because it's running a default, unpatched installation of Solaris 1.1. Combine this with the fact that the professor (or grad student; some of them get nice toys too) might use the machine for accessing the MVS system that all but governs the Uni. All it takes is a keystroke sniffer (I've seen many a professor do an "xhost +" without thinking twice!) and anyone with a malicious streak can have access to student academic records, financial status, and so on. The same database also controls authorization students may have to electronic locks around campus (dorm entrances, labs, etc).
All this is because there is no real security for semi-private desktop systems on their network. I will admit that OTS is dilligent about keeping tabs on router statistics and alerting offending users. Still, anyone that has an active ethernet drop in their office can hook anything at all to it.
Hopefully, this is a wake-up call to the upper echelons of the IT department to clean up their desktop administration policies. Maybe firewalling IS the way to go... UT as it is eats up more than one class B IP block.
IANAL, but as I understand it, you must make an effort to defend any patent you are issued within a reasonable timeframe or the patent can be contested. Unless this guy lives under a rock, he should have been aware many years ago of eBay and other online commerce sites.
Second that on the Rio Volt / iRiver players. They work with every single samplerate + bitrate combo, understand UDF (if you're so inclined), are very durable, flashable, and pretty much universally available. The software is well-designed (esp. the latest versions) and isn't impeded by the bugginess that many other players on the market exhibit. Sound quality is above-par, with the only real audible flaw being that the original (IMP-100 / Volt SP100) has a relatively weak amplifier.
If this were extended to having two read/write servos, and if it were cached like most modern hard disks are, then wouldn't the Japanese be creating the Beast with Two Write Backs?
Note, too, that the amplifier's final section is on the opposite side of the board from where the ATX audio connectors are. I'm no analog guru, but I'd bet dollars to donuts (mmm... donuts) that those traces running right under the PCI slots will pick up a ton of noise on the way. Besides, with a P4 CPU, you can emulate the tube's distortion in software.
Save the money and buy a good sound card with a high SNR (Turtle Beach Santa Cruz (plug,plug))
I work at a company that does firmware for these devices. One of our coders said that he'd put in the time to make Vorbis work in our reference code if only someone could cough up a fixed-point Vorbis algo. Considering that many of the players on the market start with our code base, this is a great opportunity for some mad coder out there to become a folk hero.
Lat I checked, Verilog wasn't even a company. I bet you're thinking of Xilinx or Altera. Note that Xilinx gets badass points for providing free development tools that aren't half bad, even if they are for Windoze.
As far as speed is concerned, there are two big factors that determine how fast you can run a hardware implementation of a design. First, there's the maximum clock speed of the FPGA. This is a parameter of the FPGA used, and, like CPUs, varies with the manufacturer and model. While it is possible to circumvent this with totally asynchronous designs, as you're not required to use the chip-wide clock, it's only practical in only a few unique applications (ARM AMULET). Second, the size of the design will affect the speed at which it will run. A simulation of an Athlon or a Pentium III (excluding large memories, like caches and ROMs) will be forced to run slowly because the propagation delay between far away cells in the FPGAs and, in extreme cases, between individual FPGAs themselves, will be too great to support high clock speeds. Plus, the gate propagation will be slower in an FPGA than on raw silicon. This factor is also somewhat dependent on the HDL CAD tool used and how smart its automatic floor planner is. Now put something simple like an ARM in an FPGA, and you can probably hit much higher speeds.
It's a Cirrus EP7212 (I think, may be a 7312). Anyway, 74MHz ARM720T, memory controller, dual RS232 UART, dual audio CODEC interfaces, LCD, RTC, serial bootstrap (all you need to do the initial flash load is access to the UART0 RS232), and power management. Linux runs on these, as well as a bunch of other RTOSes.
I've heard a lot of people whine about how they wish that OGG would be supported on their Rio or Nomad or whatever. As somewhat of an insider in the portable MP3 player industry, I can say that the people who code the player applications for these devices wish that they could get their hands on a fixed-point algorithm for decoding Vorbis. If someone were to write a proof-of-concept library or application and put it up on Freshmeat or Sourceforge, I'd personally insure that it gets in the hands of the right people.
Why fixed point? All of the portable, mobile, and stereo component MP3 players are based around microprocessors that don't have any hardware floating point coprocessors. Since software FP is too sluggish, an efficient way of doing the Vorbis decode with integer operations alone is necessary.
If anyone is interested, don't hesistate to email me at the address above. No promises, but I might be able to get some development hardware for whoever is interested...
Dual EtherMACs, triple host USB ports, phat FPU, audio, VGA/LCD/TV, 200MHz ARM920T core. It's supposed to cost less than this MCM kludge and be available sooner. Did I mention that it will run Linux?
Slashdot Mirror
There's something wrong with you if most of your freshman year of college is spent looking up copyright statistics.
When I was an admin at Univ. of Texas at Austin, we upheld the same idea, calling it the 'Friday Rule'. Unless something was outright broken or a big shot professor needed something done, no hardware work, software installs, config file changes, database rebuilds, or anything else potentially destructive would be allowed to happen on a Friday to a production machine. Test machines and desktops not running any simulations (we got a lot of VLSI / circuit sim jobs) were fair game though.
Sure, like Joe Terrorist will just send this to his printer to make at-home SARS. Why not a plane trip to China to collect a few blood samples?
Hey, a used sock and some duct tape kept the Apollo 13 crew breathing for a few days.
A quote from DNA and no mention of Marvin? It's my opinion that the first servile AI systems will not be rebellious. Rather, they will be resigned to their fates and just become utterly depressed and paranoid. And whinge about the pain in their diodes down their left hand side.
Funny thing is, SonicBlue never made any of their own MP3-CD players. The first few (100, 90, 250) were all rebadged Reigncom (the OEM for iRiver) models. The latter ones (150, 350) are made by some Chinese OEM (Starlite maybe?)
You already decided to vote with your dollars. 4/1 shenanigans is a staple of the Slashdot community. So, 1.37 cents of your dollar-votes went towards supporting April Fool's Day this year. I hope that eventually you can accept that you got something of equal or greater value than what you paid for.
And I also hope that, like the other whiners out there, you get a fucking clue.
Well, the semiconductor industry uses what amounts to overgrown microwave ovens for generating plasmas for ion implantation and etching of wafers...
Could be because Business Week's readership is interested in profitable ventures... Hence the name.
I wasn't trying to be TOO sarcastic, but fair enough...
Analog signals, like those that come from the RCA outputs on your CD player, can be affected by every stage along the way from the CD player to the speakers. In that signal path, noise (static, resistor noise, AC hum) and distortion ('clipping', not-quite-linear amplifiers) can creep into the signal. You may notice that most stereo equipment documentation mentions a signal-to-noise ratio (SNR). This is a measurement (though standards DO vary and you can easily make it misrepresent reality) of the decibels between the noise floor (the average of non-signal) and the maximum signal that an audio network can pass (often a 1kHz sine wave). However, the smallest signal that can be represented with a 16-bit digital source (CD audio, your MP3 player, etc) occurs at -96dB (20*log10(2^16))
Let's say that your stereo receiver claims a -100dB SNR (which is pretty average for most midrange consumer receivers) for the analog inputs. Assuming you have a good, solid connection in between the input device (let's assume it's your CD player again, and that its output can represent all 16 bits, aka -96dB) and the receiver, there will be 4dB of headroom that your receiver will provide. This is more than adequate for CD audio, but for >16 bit digital sources (DVD, HDCD, etc) this may not even be enough.
So why do some CD players sound better over a digital link? For CD audio, the reason lies in the CD mechanism itself. The data stream coming off a CD is regulated, or 'clocked', at 44.1kHz. That means that one bit of audio data gets cranked out every 1/44100th of second. This clock is regenerated from the bitstream on the CD itself, much like an RS232 receiver regenerates the baud clock from the incoming data. The digital signal being cranked out of most CD players, as well as the DAC inside the player, are themselves clocked from this regenerated signal. Problem is, the mechanical nature of the CD system can induce jitter, which is an timewise inconsistency in that clocked data. Jitter comes from everything from thermal noise to a crappily mastered CD. If you graphed the clock coming from the CD player's chipset (often called the 'servo chipset') on an oscilloscope, you would see the signal jiggle left and right randomly (hence the term jitter). The way this jitter affects you is that it misrepresents the digitally-encoded data to the DAC in the time domain, causing all sorts of distortion artifacts. This kind of distortion is often seen on an FFT as harmonics of the actual audio.
If you use the digital-out on your CD player to attach to your receiver, then you shift the responsibility of the digital-to-analog conversion to the receiver. Fortunately, your receiver has a DSP (of which my employer makes many of) that can not just regenerate the digital audio clock, but make corrections to it so that it is consistent when it gets converted to the analog domain.
But with MP3 audio, especially with a component MP3 'receiver', this digital clock is generated by the device's CPU, which is in turn being created from a stable source like a crystal oscillator. Inherently the analog audio coming out of such a device is more true to its digital representation than a CD. This comes at a price, though. All compressed, lossy audio formats make assumptions about the listener and cut out not-so-critical parts of the audio to save bandwidth. This results in some harmonic distortion being added in when the music is regenerated. For that reason cymbals don't sound so sharp and voices lose their presence when you listen to them in MP3 format. Audiowise, you're back to the same place you were when you were listening to your CD player's analog output, even if you use a SP/DIF cable to connect the MP3 deck to your receiver.
IANAA (not an Audiophile), but this is what I know from working with portable MP3 devices on the job.
Wait... Let me see if I got this right:
You want this snazzy MP3/WMA/(insert other compressed audio format here) player. But you wouldn't buy it because it doesn't have digital audio out so you can get that 'CD' quality sound?
I can think of some technical reasons why they don't do this. Maybe they change the clock rate of the DACs to match the sample rate of the MP3 being played. Then an additional (costly) sample-rate converter would need to be added to maintain a constant SP/DIF clock. But even still, unless you encode your music at break-even compression ratios, the audio's bound to sound just as good being piped out in analog as in digital form.
Believe what you want about compressed audio. If you ever do buy such a receiver, I'd be glad to sell you some gold-plated Monster Cable TOSLINK cables to go with that.
You're probably right in suggesting that the issues with security at UT is a problem of scale. I would imagine that the theft wasn't caused by incompetent admins so much as lack of administrative control.
I used to be an admin at the UT-ECE (Elec. and Comp. Engineering) department. I was in charge of running the Sendmail system and Linux desktops for about 6000 users or so. Keeping security on these specific machines was mostly a matter of staying up to date on the latest vulnerabilities (thanks, Bugtraq) and keeping an ever-watchful eye on the logs.
The problem is that there are a lot of *NIX workstations scattered about the university that have been running with no security in place for years. It's not uncommon for a professor to have a Sparc-20 on his desk that he uses for day-to-day work get rooted because it's running a default, unpatched installation of Solaris 1.1. Combine this with the fact that the professor (or grad student; some of them get nice toys too) might use the machine for accessing the MVS system that all but governs the Uni. All it takes is a keystroke sniffer (I've seen many a professor do an "xhost +" without thinking twice!) and anyone with a malicious streak can have access to student academic records, financial status, and so on. The same database also controls authorization students may have to electronic locks around campus (dorm entrances, labs, etc).
All this is because there is no real security for semi-private desktop systems on their network. I will admit that OTS is dilligent about keeping tabs on router statistics and alerting offending users. Still, anyone that has an active ethernet drop in their office can hook anything at all to it.
Hopefully, this is a wake-up call to the upper echelons of the IT department to clean up their desktop administration policies. Maybe firewalling IS the way to go... UT as it is eats up more than one class B IP block.
Gives new meaning to "Steal Your Face", eh?
"Personal note: When I was little my mother told me not to stare into the sun, so when I was six I did."
IANAL, but as I understand it, you must make an effort to defend any patent you are issued within a reasonable timeframe or the patent can be contested. Unless this guy lives under a rock, he should have been aware many years ago of eBay and other online commerce sites.
Second that on the Rio Volt / iRiver players. They work with every single samplerate + bitrate combo, understand UDF (if you're so inclined), are very durable, flashable, and pretty much universally available. The software is well-designed (esp. the latest versions) and isn't impeded by the bugginess that many other players on the market exhibit. Sound quality is above-par, with the only real audible flaw being that the original (IMP-100 / Volt SP100) has a relatively weak amplifier.
If this were extended to having two read/write servos, and if it were cached like most modern hard disks are, then wouldn't the Japanese be creating the Beast with Two Write Backs?
"Personal note: When I was little my mother told me not to stare into the sun, so when I was six I did." - Max Cohen
Note, too, that the amplifier's final section is on the opposite side of the board from where the ATX audio connectors are. I'm no analog guru, but I'd bet dollars to donuts (mmm... donuts) that those traces running right under the PCI slots will pick up a ton of noise on the way. Besides, with a P4 CPU, you can emulate the tube's distortion in software.
Save the money and buy a good sound card with a high SNR (Turtle Beach Santa Cruz (plug,plug))
Write me a GPLed fixed-point OGG decoder optimized for ARM720T and I swear I'll give you, free of charge, an MP3 player that plays OGG.
I work at a company that does firmware for these devices. One of our coders said that he'd put in the time to make Vorbis work in our reference code if only someone could cough up a fixed-point Vorbis algo. Considering that many of the players on the market start with our code base, this is a great opportunity for some mad coder out there to become a folk hero.
Lat I checked, Verilog wasn't even a company. I bet you're thinking of Xilinx or Altera. Note that Xilinx gets badass points for providing free development tools that aren't half bad, even if they are for Windoze.
As far as speed is concerned, there are two big factors that determine how fast you can run a hardware implementation of a design. First, there's the maximum clock speed of the FPGA. This is a parameter of the FPGA used, and, like CPUs, varies with the manufacturer and model. While it is possible to circumvent this with totally asynchronous designs, as you're not required to use the chip-wide clock, it's only practical in only a few unique applications (ARM AMULET). Second, the size of the design will affect the speed at which it will run. A simulation of an Athlon or a Pentium III (excluding large memories, like caches and ROMs) will be forced to run slowly because the propagation delay between far away cells in the FPGAs and, in extreme cases, between individual FPGAs themselves, will be too great to support high clock speeds. Plus, the gate propagation will be slower in an FPGA than on raw silicon. This factor is also somewhat dependent on the HDL CAD tool used and how smart its automatic floor planner is. Now put something simple like an ARM in an FPGA, and you can probably hit much higher speeds.
It's a Cirrus EP7212 (I think, may be a 7312). Anyway, 74MHz ARM720T, memory controller, dual RS232 UART, dual audio CODEC interfaces, LCD, RTC, serial bootstrap (all you need to do the initial flash load is access to the UART0 RS232), and power management. Linux runs on these, as well as a bunch of other RTOSes.
I've heard a lot of people whine about how they wish that OGG would be supported on their Rio or Nomad or whatever. As somewhat of an insider in the portable MP3 player industry, I can say that the people who code the player applications for these devices wish that they could get their hands on a fixed-point algorithm for decoding Vorbis. If someone were to write a proof-of-concept library or application and put it up on Freshmeat or Sourceforge, I'd personally insure that it gets in the hands of the right people.
Why fixed point? All of the portable, mobile, and stereo component MP3 players are based around microprocessors that don't have any hardware floating point coprocessors. Since software FP is too sluggish, an efficient way of doing the Vorbis decode with integer operations alone is necessary.
If anyone is interested, don't hesistate to email me at the address above. No promises, but I might be able to get some development hardware for whoever is interested...
What you really want is one of these.
Dual EtherMACs, triple host USB ports, phat FPU, audio, VGA/LCD/TV, 200MHz ARM920T core. It's supposed to cost less than this MCM kludge and be available sooner. Did I mention that it will run Linux?