This long discussion has an awful lot of bashing
Phil about working long hours. Statements
like "From a business point of view, long
hours by programmers are a key to
profitability" sound pretty manipulative.
Much as I'd like it not to be true, there is
some truth here...
I've worked on many hardware & firware projects, often by myself, and almost every time I ended
up working a lot of really late nights. At least
for me, I can get more raw coding and design
work done in an all-night session that an entire
week of 8 hour days. Getting the environment
right... no distractions, music without lyrics,
correct room temperature, etc, makes a huge
difference. I try not to do this sort of thing
often. I try to do all-nighters more for my
own (often free software) projects more often
than I do them for my employer. (trying hard
to resist a shameless plug... the URL is next
to my user info above)
Now I think it sucks to "have no life". It think
it sucks for employers to expect programmers to
work 70+ hours/week. Phil's writing does leave
a bad taste of giving would-be managers a
formula for over-working programmers.
It is true? Yes, I think it is.
Does it suck? Yes, I think it does.
Those are separate issues. Just because it
sucks and is manipulative and/or unethecial
doesn't necessarily mean it's wrong. I think
the a number of comments posted here have
failed to make that distinction.
A computational system in which an
operational code (opcode) consisting of a sequence
of numerical data instructs an Arithmetic Logic
Unit (ALU) to perform an operation on two operands, storing the resulting arithematic or
logical result into either of the operands.
What is claimed is:
1. A computational system comprising an ALU
(Arithematic Logic Unit), c
a operational code decoder, memory bus interface, and microcoded control logic, wherein,
Arithematic Logic Unit further comprises circuitry
to perform mathematic operations of addition,
subtraction, increment, decrement, multiply,
divide, and logic functions of AND, OR, XOR, right
and left bit shift;
2. Operational code decoder comprises circuitry that extracts encoded information
to direct the activity of the Arithematic Logic
Unit (claim 1);
3. Memory bus interface that transfers
the operands required by the ALU (claim 1) and
instruction opcodes needed by the decoder (claim 2);
4. Microcoded Control Logic which sequences
the timing and produces control signals with the
proper timing to direct the activities of the
ALU (claim 1), Opcode Decoder (claim 2), and Memory Bus Interface (claim 3).
Description Of The Invention
The present invention related to the operation
of a computational device, used to execute
computational tasks, wherein the computational
task to be performed by be programmed by creating
a list of operational codes.
.
.
.
maybe someone else wants to continue this... it's late and I'm getting tired...
Damage to MS already poor reputation
on
Microsoft Cracked
·
· Score: 2
We all suspect (know) that windows is full of nasty
security holes. Whoever's got the code could
do a lot of damage to MS by finding problems
and/or writing exploits
to windows and releasing them to script kiddies,
one after another... timed to keep MS in the
news for one major security problem after
another.
Of course, this seems to be more or less happening
naturally without the source!
Katz, if you're reading this, all it took to get
this link was typing "www.ucla.com" and following
a link from their main page. Being the net savvy "internet culture" advocate you are, I'm
suprised you didn't try this.
I just noticed the name "Dragon" in both
the "Carnivore Demo Report" and "English, The Global Internet Language?" articles. Did anyone
else pick up on this? Is it the same company?
In the case of Carnivore, well, it's part of the
"DragonWare Tools". In the English article,
the speech to text converter mentioned is made
by Dragon Systems.
Ok, there's probably no relation, but being a
bit paranoid and enjoying a good (or not so good)
conspirancy theory like many slashdot readers,
I thought I'd mention it. Maybe Carvivore 3.x
will also intercept streaming audio, internet
radio, voice over IP, etc... all with textual
keyword searches and whatnot. Even if they're
not the same Dragon, it's still not a giant
stretch to envision capturing multimedia formats
(with keyword matches) in real time... but if
they are the same Dragon it'd be only a stone's
throw away....
Re:So "open" and "free" are only good sometimes ?
on
Carnivore Demo Report
·
· Score: 2
Most of the encryption experts seem to agree
that only "open" encryption algorithms can
truely be considered secure, after having
been studied extensively. Certainly in the
case of encryption, (according to the experts)
the only way to have some assurance that your
data will remain "closed" is to use an "open"
algorithm that's been extensively studied by
the experts. Sure, it's the experts who are
saying all this... but it seems to make a lot
of sense.
So, evil_roy, appealing as your comment sounds,
"I don't want someone to see what I'm doing...but I want to see their source code",
it certainly doesn't hold any weight when it
comes to encryption algorithms.
In the case of computer security, there isn't as
much agreement among the experts, but there is
a strong trend or school of thought, that says
for a system to be secure, it must be studied
extensively. There are a small group of experts
who believe in security through obscurity. In
either case, the only hypocracy here is that
a pair of dissimilar words tend to be used and
if you take them out of context, it sounds funny,
but it in fact does make a lot of sense to have
open peer review of software and algorithms
used in secure systems. The data is "closed",
but the code that prevents access to the data
should be (according to many experts) "open".
About one month ago I downloaded the latest
gimp beta version, and it really is a lot
better than the stable one. Most of what
I want to do is draw simple black-n-white
line drawings for low-res illustrations on
web pages. MacPaint 2.0 still seems to be
the best program. I was hoping to finally
be able to retire the old mac, but the gimp
still has a ways to go before it can replace
good 'ole MacPaint (from 1988).
Before it was
really difficult to draw single pixel straight
lines, but now the pencil tool has a line
draw feature. Still no tools to draw arcs, circles, etc. To get a single pixel circle,
I had to make a circular selection and fill it,
then carve away from the inside. Drawing a
circle or other simple line shape really ought
to be easier!
The new version seems to be much easier to move
selections around. Previously (stable version) I could only move the selection once, and any additional moves without using the move tool would do really strange things. Why is there a move tool anyways (still present in the beta version)? What is the purpose of the move tool? I always expect to be able to move whatever's selected with a click-n-drag.
Another minor
annoyance is with pasting from the clipboard,
where there is no current selection. It seems
to always paste to the center of the image,
which is almost always off screen if you're
zoomed in to a small part of the image. Most
commercial programs paste to somewhere that
is in the currently visible view, since you
did a paste presumably to add to part of the
section you're viewing.
When moving a selection, there doesn't seem to
be a modifier key to press/hold during the move, that constrains the move to be only horizontal or vertical. From the Mac, I expect to be able to
hold the shift (or some other modifier) while
I click-n-drag the selection, and have it only
move horizontal or vertical, depending on the
initial direction of my mouse movement. I think this is a really basic and very important feature and I'm amazed that it's still not in the gimp. Maybe there's some modifier I don't know about? I tried every reasonable key, and I spent quite a bit of time looks at on-line docs, which spend lot of time on the filters and color issues, but never
seem to document the basics, like which modifier keys do what for each tool.
Rotating a selection by increments of 90 degrees ought to be "perfect"... the pixels should only move and not be changed. The stable gimp fails miserably, but the beta version works pretty well, with only a minor bug where the resulting selection shaves one pixel width off the side. Better, but still a bug you'd not find in a commercial package. Some packages have separate
tools for rotation in 90 degree increments, but
the gimp does not, and the transform still doesn't work properly for 90 degrees!
The gimp is cool, and it's a great program considering that it's free... but it's still
lacking in the user interface. My overall
experience is that it does really amazing
things, but when you only want to do something
simple, the user interface can be annoying.
on the other hand, how far away are we from people having enough processing power to not want/need to
upgrade anymore?
Natural language and speech processing will
be among the compelling reasons to upgrade
to what today seems like overkill processing
power... if Moore's law holds out, that is.
Today, if I write a program and it has a bug
or design flaw that causes a security hole,
eventually someone will discover it. There's
a good chance they'll be seeking some fame for
themselves and create a lot of bad press for me.
There's a reasonably good chance they'll write
an exploit easily usable by script kiddies,
which is going to make my security minded customers pissed off. If I'm good at PR (like MS)
I might be able to direct my customer's
frustration at the guy who wrote the exploit or
at hackers using it. Even in the best case, full
disclosure ends up costing the vendor more time and
money than keeping it a secret.
The point is that with the practice of full
disclosure, there's a real opportunity for upset
customers and damage to reputation for the vendor
who released buggy software..... I'd guess that
software vendors would do even less testing and
concentrate even less on security if they knew
they were free from the risks associated with
full disclosure.
If anything, what's needed is something that
punishes software vendors for buggy code.
I'll probably lose a bit of karma for this troll, but here's how I read the article:
Yes, we're the hardware and software manufactures,
big and small (aka ipo craze) we (snif) we're
being bullied for the big bad RIAA. We're wimps
and can't stand up to them. We'd try, but we're also whores to the almighty dollar, so at least some of us would break the ranks. That's
why we all had to join the SDMI against our (pathetic) wills. We know they're wrong,
but we're so gawd damn helpless that we're sinking to new lows to feed the press a bunch of lame-ass whining that
you hackers are "idiots" for not trying to break
SMDI now. We obviously hold no respect for you hackers, but you're our last chance at being saved from having to spend our
money to implement it.
We're pissed that you're boycotting,
because we know you'll break the watermarks
eventually and probably after we've been forced (remember we're wimps to the RIAA) to spend our
money.
We really couldn't care
less if consumers lose their rights or if SDMI gives up or tries something better.... we just
wanna get SDMI hacked before we have to spend our
money on it. That's all we care about, saving
our money from implementing their won't-work watermark scheme. You hackers are idiots for not jumping in now to save our money!
I recall from my own personal memory that even in the early 90's there was a debate over this - during the BBSing days. This would be circa 1992. One thing is certain - this isn't a new issue.
When I started using computers in school (1981), it was the Apple ][. Arcade games were popular, and games similar to their popular arcade counterparts were sold for the Apple computer on copy protected media.
A copy of the game was said to be cracked when it was duplicated to a standard format disk with modifications so that it would run from the standard disk instead of the original copy protected format. The "crackers" who did these deeds almost always added a startup screen early in the boot process that proclaimed their deeds. The word "cracked" was universally used in these startup screens.
As a display of their great skills, the "crackers" would greatly compress their images, usually with custom coded compression (8 bit 6502 asm code), and display them very early in the boot process, so that the image would appear almost immediately.
Great effort was expended in these start up screens, some even animated through the boot process. Every "cracker" wanted whoever got ahold of their work to know who "cracked" it, even though only though a useless alias name.
Everyone I knew who was "into computers" wanted to learn how to "crack" protected disks. Sometime in about '85 ot '86, I went to some user group meetings. There was a guy there who supposedly was a "cracker" and there was much interest in a seminar or workshop about cracking.
Towards the end of my high-school days (1988), I
became pretty good with assembly and I was given
a copy of "beneth apple dos", and together with lots of text files downloaded from "cracking BBSs", I eventually learned how to "crack" many of the current protection schemes. I never created any of those silly startup screens!
The one computer teacher at the school (who did
know a tiny bit of pascal and could do simple things in applesoft basic) saw some lame show on TV and believed that "cracking" applied to modem based activities, and "hacking" refered to non-network jobs, including breaking copy protection. My believe was more or less the opposite. We had a long arguement... the fact that virtually every single pirated program had a startup image saying "cracked by XXXX" obviously meant nothing compared to the obviously true documentary as seen on TV.
So maybe I was wrong, but it's a fact that the word "cracked" was used on all those little startup images on hundreds of de-protected games.
The 80's are ancient history now-a-days, but
indeed the word "crack" was certainly in widespread use way back then.
The word "phreaking" (or something similar) was commonly used (1980's) to refer to telephone mods used to get free phone calls or other phone system tricks. I read about these things, but I had little interest and it seemed quite risky.
Re:Some applications need the fastest cpu
on
Pentium 4 Delayed
·
· Score: 1
Go SMP.
Yeah, that's the answer, for a closed-source
single threaded application, that is a compiler
for a FPGA chip whose silicon-level details
are a close gaurded proprietary secret! You'd
have to no only reverse-engineer the software
but the chips as well, and the EULA won't allow
it.
Even if the code were open source (or available
with a restrictive license), and even if there was some straightforward way to make it multithreaded (has anyone even figured out how to truely utilize multiple CPUs in a C compiler, and make -j doesn't count).... even if you had a reasonable chance of hacking on the code to mulitthread it, if the goal is to save time, buying a faster CPU is probably the best move.
Some applications need the fastest cpu
on
Pentium 4 Delayed
·
· Score: 1
but considering what intel was charging for the things, I can't imagine who would buy one.
I'm working on a project with a FPGA chip. It takes my 800 MHz machine about 1.5 minutes to compile the chip's design, using the
Xilin x Foundation Software, for a relatively small design without much synthesis! Even a tiny change to just one gate and I've got to wait 1.5 minutes. It was about 5 minutes before I upgraded the CPU to 800 MHz. My chip is a 10k gate (supposed capacity). It's hard to imagine how anybody can compile designs for the
really large devices. I suppose they use more high-level simulation and don't do as much in-circuit download. Whatever they do, I'd image that companies paying top dollar for engineers to sit in front of slow software will be among the first in line for faster cpus!
There are lots of other high-end applications like this. The low-cost PC is the bulk of the market, without a doubt, but it doesn't take a lot of imagination to see high-end applications that really need more CPU horsepower. If I'm still doing a lot of FPGA work when the chips are actually available (at $1000 to $1500), I might even upgrade my own home machine!
Procomm Plus -- The last thing Linux needs is another terminal emulator.
Actually, I would really like to see a good
terminal emulator for X11. Maybe there is one
and I'm just not aware of it? I use seyon
(which isn't included in redhat's install anymore). Seyon works pretty well, but there are a number of places where it leaves a bit to be desired. Several times I started to look at
the code for seyon, but I guess its good enough
that I haven't been that motivated to hack on it.
When, exactly, did the content industry (by which I mean, of course, the typical
entertainment media conglomerates, as well as other businesses/artists/providers who are
happy to receive money for what may or may not be quality stuff) start treating their
consumers as "the other side," waging a continuous and pointless war?
Probably about the time
macrovision came into widespread use and VCR manufacturers adjusted the time constants in their VCR's AGC circuits to avoid recording signals with the macrovision pulses in them. Ok, that's hardly the exact time
that technology came into use that presumed the user to be a pirate... I remember all sort of very interesting floppy-based copy protection on the Apple ][ software. FWIW, strong floppy-based copy protection did ultimately turn out to be a pointless war, but macrovision is here to stay.
The thing I can't figure out about SDMI is what
happens if rouge hardware manufacturers make
players that don't check for the watermarks.
For example, I'll never put any code in
my little MP3 player to check for watermarks. I guess
my little project doesn't matter in the grand
scheme of things... but if there's a market
for non-SDMI players, I'm sure there are lots
of folks who will provide them in the interest
of making a buck. There just isn't any security
in CDDA format, other than watermarks, and watermarks will only work if other devices check for them.
Modern SDRAM latency is less than 10ns. ROM latency is about 150ns.
Back in the old days before SDRAM, DRAM memory
speed was usually discussed in terms of the access time, which improved from about 150 ns in the Apple2 days to about 60 or even 50 ns when EDO DRAM was the most commonly sold. Even this access time spec was a bit misleading. Access time is the time from the beginning of any access (assering the RAS signal) until the data pins have valid data on them, and it doesn't tell the whole story about how rapidly you can really go about getting what you need.
Nowadays, SDRAM is the standard memory type, and all of a sudden, out of nowhere, the spec went from 60 ns to 10 ns! What did not happen is a six fold increase. The SDRAM "ns" spec is the period of the clock, to which all the other waveforms are sync'd. To access a SDRAM, you need to spend at least one clock giving it the row address (just like the RAS and row row addr for async DRAMs). Then you need to wait either 2 or 3 clocks (it's always 3 when used at the maximum clock) to get the data. This 2 or 3 delay is what's called the CAS latency, and many PC BIOS config let you change it.
SDRAM certainly is fast, but to say that the latency is 10ns is absolutely false. What is so good about SDRAMs is that the signals are sync'd to the master clock, and that the chips have interleaved banks that work together with the page mode accesses. I'll ramble on about that in a moment, but first a tiny bit of background...
All DRAM is arranged with the memory cells in rows and columns. An 8Mbit chip may have 1024 rows, 1024 columns, where each cell is 8 bits. To read or write any part of the chip, you first select the row, then select the column, and then go about your business. DRAM cells store information as charge on tiny capacitors. These capacitors slowly lose their charge, so they have to be recharged regularily, or the information will be lost. This process is knows as DRAM refresh.
DRAM memory reads are always destructive. When a row is selected, all the data from that row is transfered to a buffer. The tiny capacitors and the single transistor that's built with each one drive a fairly long column wire, which ultimately connects to a sense amplifier, and those amplifiers load the data into the buffer. At this point, all the memory cells in that row have lost their data, but that data is located in the buffer.
The second step to access DRAM is to select the column. With async dram, the CAS signal strobes the address pins (which had better have the desired column address). With SDRAM, the address pins are expected to have a valid column address before the next clock (setup time). For reading, the chip connects to portion of the row buffer to the data bus, and for writing whatever's on the bus is written into the portion of the row buffer that corresponds to whatever column address is selected. After you've made all your column accesses (all within the row you originally selected), you deassert the control signals, and the chip stores the buffer back into the correct row. This is known as the "precharge time", and it takes almost as long as the access time. For a 60 ns EDO DRAM, this would be about 45 ns... so for random reads (not the same row), you'd only be able to do one every 105 ns!
Fast page mode DRAM (were there ever any DRAMs that didn't do this?) allows you to perform multiple operations on the same row, by deasserting the CAS signal to end the current operation and then reasserting it again for the next. EDO DRAM is basically the same thing as FPM, but they made a minor change so that when reading, the bus would remain driven even after CAS was deasserted. This allowed DRAM controllers to deassert the signal (necessary before reasserting it) before getting the data from the DRAM. There was a lot of hype about EDO, and it did indeed have higher system bandwidth, but in truth it's just a very minor change in the design.
SDRAM works more or less the same way, but with a clocked interface. Like a lot of technologies, there's been a lot of misleading marketing hype about how great SDRAM is, but it really is just a new front end (with some advantages) on top of the same old DRAM technology. Not having designed a working SDRAM controller (yet), I'm speaking from less experience... mostly just reading data sheet and app notes. To access the memory, you assert RAS and deliver the row address on the first clock (everything is setup and hold relative to the master clock). You deliver the CAS and column in the next clock, and then wait either 2 or 3 cycles for the data. Just like all other DRAMs, you can access mulitple columns in within the same row. This page mode access is what's really fast about SDRAM.
SDRAM chips have either 2 or 4 banks of memory, and they support an interleaved access mode, where you can read from alternating banks on each clock cycle. This is what allows a SDRAM to actually deliver data every 10ns. A 4 bank SDRAM is actually 4 banks, each allowed to take 40 ns for each column, but the system can read a new column every 10 ns! DIMMs are 64 bits wide (usually 8 chips each 8 bits wide), so you're getting a lot of data very rapidly... but only from within a small block (one row), and only after you spent some time selecting the row, and don't forget that when you're done within that row, you'll have to wait through the precharge time before you can select another row.
The interleaving trick was possible with older FPM DRAM chips, where you'd select a row from two SIMMs, and then read columns alternately from each one. I recall the Apple did this in some of their (then) high-end Macs. EDO doesn't allow this, unless you have two separate data busses, because the EDO "tweak" is to keep the output drivers turned on after CAS is deasserted, until the entire row access is over (RS deasserted).
So, dear reader, if you've read through all this long winded posting (which is actually a rough draft for a part of a web page about the DRAM controller in my little mp3 player project), the main point is that DRAM is arranged in rows and columns, and to access the DRAM, the DRAM controller has to go though a few steps. The really fast data rates one typically hears about are only the special case where you're accessing multiple columns within a single row, and that row selection and precharge time are important, even if they're not the specs commonly mentioned.
The really fast page modes (all DRAM types, particularily SDRAM) are really quite useful for modern computers, because the CPU never really accesses the DRAM... it always communicates with a fast cache memory, and the DRAM controller's job is to fill and flush cache lines (groups of bytes) from/to the DRAM, which always results in accessing consecutive columns within a row.
So to finish up and bring it around full-circle, Dave Zarzycki's comment not only mistakes the SDRAM clock period for latency, but also ignores the fact that the SDRAM or ROM will only be accessed for cache misses. For a large ROM (like the linux kernel being discussed in this thread), cache misses will be an important factor. Nonetheless, it's not valid to simply compare the single marketing-published (unrelated) numbers for chips and not consider their interactions with the system and its cache.
I said Rob was rubbing a $450 gizmo in our face and calling it inexpensive.
I'm finally getting around to reading through the comments, after a long day of (trying in vain) to deal with the slashdot effect, getting people's boards ready, and answering hundreds of emails.
I've spent many many hours designing this player to make is affordable. I originally wanted to make it under $100, and I might have been able to get close to that without the power supply and DRAM controller. It's been a tough project with a lot of little twists and turns, which you can read about (more or less) on my web site's
history page, linked at the bottom of the
recent news page.
It's a bit disturbing to see a project that I've poured all my free time and energy (and a lot of money), as well as accumulated vacation time from work, described as a $450 gizmo. I can see how, to you, it's a "gizmo", but it's certainly not $450. We're selling the assembled boards for $150. Now, admittedly you need to add stuff. There are a large number of people who have or have access to obsolete computers with SIMMs, hard drives and power supplies. If you're in that group, you'll be able to get it going without spending anything more. The board currently doesn't use the SIMM, and laptop drives start at about $140 for the smaller capacities. Standard drives are often available for about $80, and it's possible to use a standard drive, admittedly with an external power supply, which also is readily available in the PC component marketplace at low cost. Sure, you can buy the 80 gig drive, but saying something looks cool (or uber pimp, as the case may be) because it can go up to 80 gigs is a long ways off from "rubbing it in your face" (at the highest possible price). I'm amazed you can see Rob's posting in this light. I suspect viewpoints like this come from spending one's creative energy hating successful people rather than directing it into activities that might make you a success as well.
Also, Rob and Slashdot do not get a commission. There is no kickback. We're far too small to even be able to make a meaningful kickback. I like a good conspiracy, but there just isn't one here. Several days ago I offered to send a free board to Rob for eval, but he declined, even when I offered to send it with a pre-loaded hard drive, power supply and speakers.
Rob's a really busy guy!
Hi, Paul here. I'm really sorry that my little website is buckling under the weight of the slashdot effect. I moved all the images to a
virtual hosted (faster) server, but the slashdot
effect is indeed formidable!
Here is a mirror of the MP3 Player portion of the site. The links to the on-line store and
the non MP3 player material will still take you back to our (very slow) server, but at least you'll be able to browse the info about the player.
Please use this mirror instead of the google
cache, because there were a large number of
additions to the web pages in the last couple
days, including the GPL'd firmware source code.
I hope you find the player interesting, perhaps even uber pimp (whatever that means?)
September 13, 2000 -- Today three major
manufactures of removable magneto-optical (MO)
media agreed to proto the installation of a
Media ID, aimed at protecting copyrighted
digital content.
The media ID will apply to new discs with the unique media ID factory programmed, announced
company officials, which combined with media
access software requiring the IDs will create
new market opportunities for the media. Officials
also commented while the MO discs with a media ID will read with legacy MO drives, new Media ID-compatible MO disk drives will be required
to enable content playback with Media-ID aware
client agent software, creating additional market opportunities for the new Media-ID aware drives
that will be required for content playback.
The companies participating in the Media ID initiative plan to make the function compatible with the copyright protection function that Microsoft Corporation will add to its forthcoming Windows Millennium Edition. By bundling media
access control with protected industry leading proprietary software from Microsoft, the participating companies, copyright protection will be enhanced by control of the platform and
software that access the Media-ID.
Saving information to a removable MO disk with the Media ID function not only protects copyrighted content distributed over the Internet but also makes it possible to save an unlimited amount of information by simply adding more MO disks.
Because Media-ID discs will be required, MO
discs which have enjoyed an average annual growth rate of 140% on the number of units sold, are
expected to become be in even greater demand,
thereby promoting the further acceptance of MO technology.
Saving information to a removable MO disk with the Media ID function not only protects copyrighted content distributed over the Internet but also makes it possible to save an unlimited amount of information by simply adding more MO disks, as well as easily carry information and store it safely and conveniently, even when replacing computers. Indeed, because protected copyrighted
digital content will be protected by the unique Media-ID, the MO manufacturers forcast an additional demand for the MO Media-ID enabled discs, as consumers carry and safely store their
copyrighted digital content rather than copy it digitally over the internet. They further believe that the realization of an environment which protects intellectual property and the popularization of a new removable memory media used with it will lay the groundwork for various types of new content businesses.
Perhaps slightly off-topic, I find that the main
bandwidth abuse of my site, which robots.txt is
completely useless in preventing, is people running
archiver programs like Teleport Pro, WebZIP,
WebReaper, WebCopier, WebSymmetrix, Offline Explorer, and Wget. Some of them try to send
a user agent string of "Mozilla" or "Mozilla/4.0",
but looking through the log files it obviously not an interactive user who rapidly downloads every single file as fast as the connection will support.
If any of you web admin gurus (I know you're reading) have any ideas of how to deal with these
programs, I could really use some help. I'd like to detect them and feed them the files at a controlled bandwidth.
I find these archiver programs usually (but not always) behave much worse than any robot... often times they completely saturate my bandwidth for many minutes. Not nice.
Indeed the licensing is expensive, but you can
buy a chip from SGS Thomson that does all the
work. It's the
STA013. The purchase price
of the chip includes the license pre-paid. Kind of interesting that it's Thomson that controls the
MP3 license fees. Somehow I doubt they'll make their chips able to do Vorbis or other formats. There is
another chip that's actually easier to use and comes with the license pre-paid, but it is considerably more expensive. Chips like
that cool looking new thing from Cirrus/Crystal are really just microcontrollers and it looks like you need a license, and it's not even clear from their website if the object-code-only library is provided for royalty or free (beer).
For a player that fits into the world
envisioned by Thomson & Fraunhofer IIS-A,
it's really not that expensive to make a
cool MP3 player...
<shameless plug> ...like this one that I've been working on lately.
</shameless plug>
Mayan astronomers predicted the end of the world to come Sunday, June 12, 2012.
Well, until then it's just vapor, like all those other predictions that didn't come true.
I'd guess you'd have better luck betting on Microsoft finally fixing all those BSOD's and Apple finally delivering protected memory management... maybe even before the apocalypse, in 2012!
Actually, my little home-grown MP3 player can play for about 1 hour without any buffering, from four AA NiMH cells. That's playing the MP3s and running the laptop drive (a 12 gig Hitachi drive), in it's high-power active mode, all from the batteries.
When I get the DRAM controller integrated with the rest of the design, I'm expecting to get at least 6 hours from four AA size NiMH batteries, perhaps more... I think 10 hours will turn out to be the upper limit I could get from my design. My testing is based on the NiMH 1500 mAH rated batteries that are available from Radio Shack.
The really cool part is that the DRAM controller is implemented in a firmware configured FPGA chip, so a no-buffering board can be flash upgraded to have a hardware based DRAM controller and high speed DMA (req'd to minimize the time the drive is sucking 5 watts from the batteries).
Slashdot Mirror
I've worked on many hardware & firware projects, often by myself, and almost every time I ended up working a lot of really late nights. At least for me, I can get more raw coding and design work done in an all-night session that an entire week of 8 hour days. Getting the environment right... no distractions, music without lyrics, correct room temperature, etc, makes a huge difference. I try not to do this sort of thing often. I try to do all-nighters more for my own (often free software) projects more often than I do them for my employer. (trying hard to resist a shameless plug... the URL is next to my user info above)
Now I think it sucks to "have no life". It think it sucks for employers to expect programmers to work 70+ hours/week. Phil's writing does leave a bad taste of giving would-be managers a formula for over-working programmers.
It is true? Yes, I think it is.
Does it suck? Yes, I think it does.
Those are separate issues. Just because it sucks and is manipulative and/or unethecial doesn't necessarily mean it's wrong. I think the a number of comments posted here have failed to make that distinction.
A computational system in which an operational code (opcode) consisting of a sequence of numerical data instructs an Arithmetic Logic Unit (ALU) to perform an operation on two operands, storing the resulting arithematic or logical result into either of the operands.
What is claimed is:
1. A computational system comprising an ALU (Arithematic Logic Unit), c a operational code decoder, memory bus interface, and microcoded control logic, wherein,
Arithematic Logic Unit further comprises circuitry to perform mathematic operations of addition, subtraction, increment, decrement, multiply, divide, and logic functions of AND, OR, XOR, right and left bit shift;
2. Operational code decoder comprises circuitry that extracts encoded information to direct the activity of the Arithematic Logic Unit (claim 1);
3. Memory bus interface that transfers the operands required by the ALU (claim 1) and instruction opcodes needed by the decoder (claim 2);
4. Microcoded Control Logic which sequences the timing and produces control signals with the proper timing to direct the activities of the ALU (claim 1), Opcode Decoder (claim 2), and Memory Bus Interface (claim 3).
Description Of The Invention
The present invention related to the operation of a computational device, used to execute computational tasks, wherein the computational task to be performed by be programmed by creating a list of operational codes.
.
.
.
maybe someone else wants to continue this... it's late and I'm getting tired...
Of course, this seems to be more or less happening naturally without the source!
Katz, if you're reading this, all it took to get this link was typing "www.ucla.com" and following a link from their main page. Being the net savvy "internet culture" advocate you are, I'm suprised you didn't try this.
In the case of Carnivore, well, it's part of the "DragonWare Tools". In the English article, the speech to text converter mentioned is made by Dragon Systems.
Ok, there's probably no relation, but being a bit paranoid and enjoying a good (or not so good) conspirancy theory like many slashdot readers, I thought I'd mention it. Maybe Carvivore 3.x will also intercept streaming audio, internet radio, voice over IP, etc... all with textual keyword searches and whatnot. Even if they're not the same Dragon, it's still not a giant stretch to envision capturing multimedia formats (with keyword matches) in real time... but if they are the same Dragon it'd be only a stone's throw away....
So, evil_roy, appealing as your comment sounds, "I don't want someone to see what I'm doing...but I want to see their source code", it certainly doesn't hold any weight when it comes to encryption algorithms.
In the case of computer security, there isn't as much agreement among the experts, but there is a strong trend or school of thought, that says for a system to be secure, it must be studied extensively. There are a small group of experts who believe in security through obscurity. In either case, the only hypocracy here is that a pair of dissimilar words tend to be used and if you take them out of context, it sounds funny, but it in fact does make a lot of sense to have open peer review of software and algorithms used in secure systems. The data is "closed", but the code that prevents access to the data should be (according to many experts) "open".
Before it was really difficult to draw single pixel straight lines, but now the pencil tool has a line draw feature. Still no tools to draw arcs, circles, etc. To get a single pixel circle, I had to make a circular selection and fill it, then carve away from the inside. Drawing a circle or other simple line shape really ought to be easier!
The new version seems to be much easier to move selections around. Previously (stable version) I could only move the selection once, and any additional moves without using the move tool would do really strange things. Why is there a move tool anyways (still present in the beta version)? What is the purpose of the move tool? I always expect to be able to move whatever's selected with a click-n-drag.
Another minor annoyance is with pasting from the clipboard, where there is no current selection. It seems to always paste to the center of the image, which is almost always off screen if you're zoomed in to a small part of the image. Most commercial programs paste to somewhere that is in the currently visible view, since you did a paste presumably to add to part of the section you're viewing.
When moving a selection, there doesn't seem to be a modifier key to press/hold during the move, that constrains the move to be only horizontal or vertical. From the Mac, I expect to be able to hold the shift (or some other modifier) while I click-n-drag the selection, and have it only move horizontal or vertical, depending on the initial direction of my mouse movement. I think this is a really basic and very important feature and I'm amazed that it's still not in the gimp. Maybe there's some modifier I don't know about? I tried every reasonable key, and I spent quite a bit of time looks at on-line docs, which spend lot of time on the filters and color issues, but never seem to document the basics, like which modifier keys do what for each tool.
Rotating a selection by increments of 90 degrees ought to be "perfect"... the pixels should only move and not be changed. The stable gimp fails miserably, but the beta version works pretty well, with only a minor bug where the resulting selection shaves one pixel width off the side. Better, but still a bug you'd not find in a commercial package. Some packages have separate tools for rotation in 90 degree increments, but the gimp does not, and the transform still doesn't work properly for 90 degrees!
The gimp is cool, and it's a great program considering that it's free... but it's still lacking in the user interface. My overall experience is that it does really amazing things, but when you only want to do something simple, the user interface can be annoying.
Natural language and speech processing will be among the compelling reasons to upgrade to what today seems like overkill processing power... if Moore's law holds out, that is.
The point is that with the practice of full disclosure, there's a real opportunity for upset customers and damage to reputation for the vendor who released buggy software..... I'd guess that software vendors would do even less testing and concentrate even less on security if they knew they were free from the risks associated with full disclosure.
If anything, what's needed is something that punishes software vendors for buggy code.
Yes, we're the hardware and software manufactures, big and small (aka ipo craze) we (snif) we're being bullied for the big bad RIAA. We're wimps and can't stand up to them. We'd try, but we're also whores to the almighty dollar, so at least some of us would break the ranks. That's why we all had to join the SDMI against our (pathetic) wills. We know they're wrong, but we're so gawd damn helpless that we're sinking to new lows to feed the press a bunch of lame-ass whining that you hackers are "idiots" for not trying to break SMDI now. We obviously hold no respect for you hackers, but you're our last chance at being saved from having to spend our money to implement it. We're pissed that you're boycotting, because we know you'll break the watermarks eventually and probably after we've been forced (remember we're wimps to the RIAA) to spend our money. We really couldn't care less if consumers lose their rights or if SDMI gives up or tries something better.... we just wanna get SDMI hacked before we have to spend our money on it. That's all we care about, saving our money from implementing their won't-work watermark scheme. You hackers are idiots for not jumping in now to save our money!
When I started using computers in school (1981), it was the Apple ][. Arcade games were popular, and games similar to their popular arcade counterparts were sold for the Apple computer on copy protected media.
A copy of the game was said to be cracked when it was duplicated to a standard format disk with modifications so that it would run from the standard disk instead of the original copy protected format. The "crackers" who did these deeds almost always added a startup screen early in the boot process that proclaimed their deeds. The word "cracked" was universally used in these startup screens.
As a display of their great skills, the "crackers" would greatly compress their images, usually with custom coded compression (8 bit 6502 asm code), and display them very early in the boot process, so that the image would appear almost immediately. Great effort was expended in these start up screens, some even animated through the boot process. Every "cracker" wanted whoever got ahold of their work to know who "cracked" it, even though only though a useless alias name.
Everyone I knew who was "into computers" wanted to learn how to "crack" protected disks. Sometime in about '85 ot '86, I went to some user group meetings. There was a guy there who supposedly was a "cracker" and there was much interest in a seminar or workshop about cracking.
Towards the end of my high-school days (1988), I became pretty good with assembly and I was given a copy of "beneth apple dos", and together with lots of text files downloaded from "cracking BBSs", I eventually learned how to "crack" many of the current protection schemes. I never created any of those silly startup screens!
The one computer teacher at the school (who did know a tiny bit of pascal and could do simple things in applesoft basic) saw some lame show on TV and believed that "cracking" applied to modem based activities, and "hacking" refered to non-network jobs, including breaking copy protection. My believe was more or less the opposite. We had a long arguement... the fact that virtually every single pirated program had a startup image saying "cracked by XXXX" obviously meant nothing compared to the obviously true documentary as seen on TV.
So maybe I was wrong, but it's a fact that the word "cracked" was used on all those little startup images on hundreds of de-protected games. The 80's are ancient history now-a-days, but indeed the word "crack" was certainly in widespread use way back then.
The word "phreaking" (or something similar) was commonly used (1980's) to refer to telephone mods used to get free phone calls or other phone system tricks. I read about these things, but I had little interest and it seemed quite risky.
Yeah, that's the answer, for a closed-source single threaded application, that is a compiler for a FPGA chip whose silicon-level details are a close gaurded proprietary secret! You'd have to no only reverse-engineer the software but the chips as well, and the EULA won't allow it.
Even if the code were open source (or available with a restrictive license), and even if there was some straightforward way to make it multithreaded (has anyone even figured out how to truely utilize multiple CPUs in a C compiler, and make -j doesn't count).... even if you had a reasonable chance of hacking on the code to mulitthread it, if the goal is to save time, buying a faster CPU is probably the best move.
I'm working on a project with a FPGA chip. It takes my 800 MHz machine about 1.5 minutes to compile the chip's design, using the Xilin x Foundation Software, for a relatively small design without much synthesis! Even a tiny change to just one gate and I've got to wait 1.5 minutes. It was about 5 minutes before I upgraded the CPU to 800 MHz. My chip is a 10k gate (supposed capacity). It's hard to imagine how anybody can compile designs for the really large devices. I suppose they use more high-level simulation and don't do as much in-circuit download. Whatever they do, I'd image that companies paying top dollar for engineers to sit in front of slow software will be among the first in line for faster cpus!
There are lots of other high-end applications like this. The low-cost PC is the bulk of the market, without a doubt, but it doesn't take a lot of imagination to see high-end applications that really need more CPU horsepower. If I'm still doing a lot of FPGA work when the chips are actually available (at $1000 to $1500), I might even upgrade my own home machine!
Actually, I would really like to see a good terminal emulator for X11. Maybe there is one and I'm just not aware of it? I use seyon (which isn't included in redhat's install anymore). Seyon works pretty well, but there are a number of places where it leaves a bit to be desired. Several times I started to look at the code for seyon, but I guess its good enough that I haven't been that motivated to hack on it.
Probably about the time macrovision came into widespread use and VCR manufacturers adjusted the time constants in their VCR's AGC circuits to avoid recording signals with the macrovision pulses in them. Ok, that's hardly the exact time that technology came into use that presumed the user to be a pirate... I remember all sort of very interesting floppy-based copy protection on the Apple ][ software. FWIW, strong floppy-based copy protection did ultimately turn out to be a pointless war, but macrovision is here to stay.
The thing I can't figure out about SDMI is what happens if rouge hardware manufacturers make players that don't check for the watermarks. For example, I'll never put any code in my little MP3 player to check for watermarks. I guess my little project doesn't matter in the grand scheme of things... but if there's a market for non-SDMI players, I'm sure there are lots of folks who will provide them in the interest of making a buck. There just isn't any security in CDDA format, other than watermarks, and watermarks will only work if other devices check for them.
Back in the old days before SDRAM, DRAM memory speed was usually discussed in terms of the access time, which improved from about 150 ns in the Apple2 days to about 60 or even 50 ns when EDO DRAM was the most commonly sold. Even this access time spec was a bit misleading. Access time is the time from the beginning of any access (assering the RAS signal) until the data pins have valid data on them, and it doesn't tell the whole story about how rapidly you can really go about getting what you need.
Nowadays, SDRAM is the standard memory type, and all of a sudden, out of nowhere, the spec went from 60 ns to 10 ns! What did not happen is a six fold increase. The SDRAM "ns" spec is the period of the clock, to which all the other waveforms are sync'd. To access a SDRAM, you need to spend at least one clock giving it the row address (just like the RAS and row row addr for async DRAMs). Then you need to wait either 2 or 3 clocks (it's always 3 when used at the maximum clock) to get the data. This 2 or 3 delay is what's called the CAS latency, and many PC BIOS config let you change it.
SDRAM certainly is fast, but to say that the latency is 10ns is absolutely false. What is so good about SDRAMs is that the signals are sync'd to the master clock, and that the chips have interleaved banks that work together with the page mode accesses. I'll ramble on about that in a moment, but first a tiny bit of background...
All DRAM is arranged with the memory cells in rows and columns. An 8Mbit chip may have 1024 rows, 1024 columns, where each cell is 8 bits. To read or write any part of the chip, you first select the row, then select the column, and then go about your business. DRAM cells store information as charge on tiny capacitors. These capacitors slowly lose their charge, so they have to be recharged regularily, or the information will be lost. This process is knows as DRAM refresh.
DRAM memory reads are always destructive. When a row is selected, all the data from that row is transfered to a buffer. The tiny capacitors and the single transistor that's built with each one drive a fairly long column wire, which ultimately connects to a sense amplifier, and those amplifiers load the data into the buffer. At this point, all the memory cells in that row have lost their data, but that data is located in the buffer.
The second step to access DRAM is to select the column. With async dram, the CAS signal strobes the address pins (which had better have the desired column address). With SDRAM, the address pins are expected to have a valid column address before the next clock (setup time). For reading, the chip connects to portion of the row buffer to the data bus, and for writing whatever's on the bus is written into the portion of the row buffer that corresponds to whatever column address is selected. After you've made all your column accesses (all within the row you originally selected), you deassert the control signals, and the chip stores the buffer back into the correct row. This is known as the "precharge time", and it takes almost as long as the access time. For a 60 ns EDO DRAM, this would be about 45 ns... so for random reads (not the same row), you'd only be able to do one every 105 ns!
Fast page mode DRAM (were there ever any DRAMs that didn't do this?) allows you to perform multiple operations on the same row, by deasserting the CAS signal to end the current operation and then reasserting it again for the next. EDO DRAM is basically the same thing as FPM, but they made a minor change so that when reading, the bus would remain driven even after CAS was deasserted. This allowed DRAM controllers to deassert the signal (necessary before reasserting it) before getting the data from the DRAM. There was a lot of hype about EDO, and it did indeed have higher system bandwidth, but in truth it's just a very minor change in the design.
SDRAM works more or less the same way, but with a clocked interface. Like a lot of technologies, there's been a lot of misleading marketing hype about how great SDRAM is, but it really is just a new front end (with some advantages) on top of the same old DRAM technology. Not having designed a working SDRAM controller (yet), I'm speaking from less experience... mostly just reading data sheet and app notes. To access the memory, you assert RAS and deliver the row address on the first clock (everything is setup and hold relative to the master clock). You deliver the CAS and column in the next clock, and then wait either 2 or 3 cycles for the data. Just like all other DRAMs, you can access mulitple columns in within the same row. This page mode access is what's really fast about SDRAM.
SDRAM chips have either 2 or 4 banks of memory, and they support an interleaved access mode, where you can read from alternating banks on each clock cycle. This is what allows a SDRAM to actually deliver data every 10ns. A 4 bank SDRAM is actually 4 banks, each allowed to take 40 ns for each column, but the system can read a new column every 10 ns! DIMMs are 64 bits wide (usually 8 chips each 8 bits wide), so you're getting a lot of data very rapidly... but only from within a small block (one row), and only after you spent some time selecting the row, and don't forget that when you're done within that row, you'll have to wait through the precharge time before you can select another row.
The interleaving trick was possible with older FPM DRAM chips, where you'd select a row from two SIMMs, and then read columns alternately from each one. I recall the Apple did this in some of their (then) high-end Macs. EDO doesn't allow this, unless you have two separate data busses, because the EDO "tweak" is to keep the output drivers turned on after CAS is deasserted, until the entire row access is over (RS deasserted).
So, dear reader, if you've read through all this long winded posting (which is actually a rough draft for a part of a web page about the DRAM controller in my little mp3 player project), the main point is that DRAM is arranged in rows and columns, and to access the DRAM, the DRAM controller has to go though a few steps. The really fast data rates one typically hears about are only the special case where you're accessing multiple columns within a single row, and that row selection and precharge time are important, even if they're not the specs commonly mentioned.
The really fast page modes (all DRAM types, particularily SDRAM) are really quite useful for modern computers, because the CPU never really accesses the DRAM... it always communicates with a fast cache memory, and the DRAM controller's job is to fill and flush cache lines (groups of bytes) from/to the DRAM, which always results in accessing consecutive columns within a row.
So to finish up and bring it around full-circle, Dave Zarzycki's comment not only mistakes the SDRAM clock period for latency, but also ignores the fact that the SDRAM or ROM will only be accessed for cache misses. For a large ROM (like the linux kernel being discussed in this thread), cache misses will be an important factor. Nonetheless, it's not valid to simply compare the single marketing-published (unrelated) numbers for chips and not consider their interactions with the system and its cache.
I'm finally getting around to reading through the comments, after a long day of (trying in vain) to deal with the slashdot effect, getting people's boards ready, and answering hundreds of emails.
I've spent many many hours designing this player to make is affordable. I originally wanted to make it under $100, and I might have been able to get close to that without the power supply and DRAM controller. It's been a tough project with a lot of little twists and turns, which you can read about (more or less) on my web site's history page, linked at the bottom of the recent news page.
It's a bit disturbing to see a project that I've poured all my free time and energy (and a lot of money), as well as accumulated vacation time from work, described as a $450 gizmo. I can see how, to you, it's a "gizmo", but it's certainly not $450. We're selling the assembled boards for $150. Now, admittedly you need to add stuff. There are a large number of people who have or have access to obsolete computers with SIMMs, hard drives and power supplies. If you're in that group, you'll be able to get it going without spending anything more. The board currently doesn't use the SIMM, and laptop drives start at about $140 for the smaller capacities. Standard drives are often available for about $80, and it's possible to use a standard drive, admittedly with an external power supply, which also is readily available in the PC component marketplace at low cost. Sure, you can buy the 80 gig drive, but saying something looks cool (or uber pimp, as the case may be) because it can go up to 80 gigs is a long ways off from "rubbing it in your face" (at the highest possible price). I'm amazed you can see Rob's posting in this light. I suspect viewpoints like this come from spending one's creative energy hating successful people rather than directing it into activities that might make you a success as well.
Also, Rob and Slashdot do not get a commission. There is no kickback. We're far too small to even be able to make a meaningful kickback. I like a good conspiracy, but there just isn't one here. Several days ago I offered to send a free board to Rob for eval, but he declined, even when I offered to send it with a pre-loaded hard drive, power supply and speakers. Rob's a really busy guy!
Here is a mirror of the MP3 Player portion of the site. The links to the on-line store and the non MP3 player material will still take you back to our (very slow) server, but at least you'll be able to browse the info about the player.
Please use this mirror instead of the google cache, because there were a large number of additions to the web pages in the last couple days, including the GPL'd firmware source code.
I hope you find the player interesting, perhaps even uber pimp (whatever that means?)
The media ID will apply to new discs with the unique media ID factory programmed, announced company officials, which combined with media access software requiring the IDs will create new market opportunities for the media. Officials also commented while the MO discs with a media ID will read with legacy MO drives, new Media ID-compatible MO disk drives will be required to enable content playback with Media-ID aware client agent software, creating additional market opportunities for the new Media-ID aware drives that will be required for content playback.
The companies participating in the Media ID initiative plan to make the function compatible with the copyright protection function that Microsoft Corporation will add to its forthcoming Windows Millennium Edition. By bundling media access control with protected industry leading proprietary software from Microsoft, the participating companies, copyright protection will be enhanced by control of the platform and software that access the Media-ID.
Saving information to a removable MO disk with the Media ID function not only protects copyrighted content distributed over the Internet but also makes it possible to save an unlimited amount of information by simply adding more MO disks. Because Media-ID discs will be required, MO discs which have enjoyed an average annual growth rate of 140% on the number of units sold, are expected to become be in even greater demand, thereby promoting the further acceptance of MO technology.
Saving information to a removable MO disk with the Media ID function not only protects copyrighted content distributed over the Internet but also makes it possible to save an unlimited amount of information by simply adding more MO disks, as well as easily carry information and store it safely and conveniently, even when replacing computers. Indeed, because protected copyrighted digital content will be protected by the unique Media-ID, the MO manufacturers forcast an additional demand for the MO Media-ID enabled discs, as consumers carry and safely store their copyrighted digital content rather than copy it digitally over the internet. They further believe that the realization of an environment which protects intellectual property and the popularization of a new removable memory media used with it will lay the groundwork for various types of new content businesses.
If any of you web admin gurus (I know you're reading) have any ideas of how to deal with these programs, I could really use some help. I'd like to detect them and feed them the files at a controlled bandwidth.
I find these archiver programs usually (but not always) behave much worse than any robot... often times they completely saturate my bandwidth for many minutes. Not nice.
For a player that fits into the world envisioned by Thomson & Fraunhofer IIS-A, it's really not that expensive to make a cool MP3 player...
...like this one that I've been working on lately.
<shameless plug>
</shameless plug>
Jakob Nielson, usability expert and author of the Alertbox Column, which many highly regard, wrote this little piece about tradeoffs between differential pricing and user loyalty. Probably an interesting read, even if you don't always agree with Nielson's opinions.
Well, until then it's just vapor, like all those other predictions that didn't come true.
I'd guess you'd have better luck betting on Microsoft finally fixing all those BSOD's and Apple finally delivering protected memory management... maybe even before the apocalypse, in 2012!
When I get the DRAM controller integrated with the rest of the design, I'm expecting to get at least 6 hours from four AA size NiMH batteries, perhaps more... I think 10 hours will turn out to be the upper limit I could get from my design. My testing is based on the NiMH 1500 mAH rated batteries that are available from Radio Shack.
The really cool part is that the DRAM controller is implemented in a firmware configured FPGA chip, so a no-buffering board can be flash upgraded to have a hardware based DRAM controller and high speed DMA (req'd to minimize the time the drive is sucking 5 watts from the batteries).