Do the same thing (try to access a defective floppy with Linux with root access to the system) and come back and tell us what happens.
Lessee... about the same thing that happens
when I do it as a mortal user. I get some
messages in the system logs about how it couldn't
read a particular sector, and that's about it.
Sometimes I get my file, but (depending on the
damage), usually I do not. Of course, I've been
reading heavily damaged disks this way.:-)
This lawyer does, I personally don't, for much the
same reasons as you mention it.
The lawyer is merely pointing out that "See, we
managed to ignore the (possibly valid and
quite important) criticisms in the gene-patent
debate, so there's a precedent." (Obviously,
I'm characterizing it quite a bit differently
than he would have me characterize it.)
"Some have criticized the patent office for issuing e-commerce patents that supposedly cover obvious variations of well-known technology," Wright said. "Some of this
criticism comes from those who are flatly opposed to software patents in any form. Similar arguments were raised years ago when biotechnology companies began
patenting new life forms and genes."
This way of arguing really slants things. The general form is devious: "Some have criticized [insert reasonable criticism here]. Some of this criticism comes from [insert more radical elements of the larger critiquing community here]. Similar kinds of criticisms were raised in [some other situation in which we ignored the criticisms]". The basic idea is to invalidate the criticisms by saying "yeah, but some of them come from really out-there people, and see, we've ignored this stuff before!"
It's kinda like guilt by association. "If you agree with these criticisms, then you must be in
this group over here which is at one extreme."
So how is this cookie insecure? I really dont follow. It makes it easy for you to order. Thats all. Very very easy.
And I suppose you like getting random pizzas at 3AM? If someone happens to get a copy of your
Amazon 1-click cookie (whether via a browser exploit, email/Word macro trojan, sniffing network traffic, whatever), then they can make life very annoying for you very, very easily.
Imagine if they sent a dozen different books a day to
you over a 1 week period. Do you really want to
deal with ~100 books arriving and having to send
them all back?
Much more annoying than prank pizza delivery.
Sure, that's just the pranksters, but its still
not something I'd like to have happen to me.
Um... yeah. If you say so. Generating the output string, eh?
Yup. Simple traceback. Plain and simple. For
each cell, move in the opposite direction from
the direction I moved to enter this cell.
Record the original movement in reverse order in
the answer buffer.
BTW, I sent you a better-documented version just
now. I realized that "ixyp" and "oxyp" aren't real nice names for variables, unless you realize I mentally read
"input x/y coordinate pointer" and "output x/y coordinate pointer". More directly, in the context of a queue, these are "head" and "tail".:-)
How many times have you been looking at old code and thought "What were they smoking when they wrote this?"
Actually, I think that very often when I look
at my own code. I don't smoke in the traditional
sense, though. The most that happens is that
smoke starts curling out of my ears after a
few Venti coffees from the local Starbucks.
According to an email I got from CowboyNeal, it's actually 50. I asked after my karma dropped by 2 after having two articles modded up to +3 and +5, and another couple modded down. The net should've
been positive, but it was negative due to the cap.
Holding up the horrific 16 to 32-bit transition debacle (as executed by Microsoft with Win9x) as a good idea seems a little odd, considering it's been 13 years since the 80386, and most users are
still crunching 16-bit code on their PIIIs and K7s.
I never said it's a great idea. It's a horrible
idea if you want good performance and a stable
(as in "not crashing") platform. It's a wonderfully pragmatic idea,
though, if you want to move billions of existing
lines of code to a new platform without (much
needed) rewriting, though.
But, that's exactly what Sledgehammer is going to get you. No "64-bit" OSes (except for maybe Linux), but instead a bunch of small incremental "Accelerated for Sledgehammer" drivers and
video games. And like, the 640K barrier before it, it's no real solution to the upcoming 4GB barrier ("ought to be enough for anyone", right?), which is the main reason you want a 64-bit chip to
begin with.
That's fine. That's what sells in the high-end
gaming market, anyway. Look at the "64-bit"
videogame systems.
I'm pretty sure he meant an in-place filesystem
conversion utility. You can convert an ext2 filesystem into an ext3
filesystem in-place. The same cannot be said for
ext2 to any of the other filesystems.
The IA-64 does not execute IA-32 via
software emulation. They do have IA-32 instruction decoders on the die.
The main issue is that IA-32 vs. IA-64 is modal,
and so you can't mix the 64-bit and 32-bit code
with a very fine granularity. From what I
understand, it the mode-switch was meant to be
thrown with about the same granularity as a context switch.
Sledgehammer, on the other hand, sounds like it's
trying to be a straight extension on IA-32, and
so would layer over IA-32 much like IA-32 layered
over the 80286, which layered over the 8086...
This would allow 32-bit and 64-bit code to mingle
within an application. (Just look at
Windows 9x for an example of a deployed system
that operates in this manner, and why Sledgehammer
might hit where Itanium misses.)
And one last thing: Itanium is the collective
name for the IA-64 platform, whether it's Merced
or McKinley, just as Pentium has become the name
for the current set of IA-32 chips. Merced
might get cancelled, leaving McKinley as the
first Itanium chip to ship. Wouldn't surprise
me in the least.
The results of the performance test that I ran were somewhat surprising - it seems the machine with the hard disk actually performed _better_ than the machine with the ramdisk. [...] and I suspect having a ramdisk hampers the
kernel's ability to manage the buffer cache.
You're partly right. The other reason is that
it forces more pages out to swap, since the
RAM disk can't be paged out (I'm pretty sure).
Placing your data in a traditional Linux RAM
disk has two bad effects:
It reduces the total amount of RAM available
to applications. This results in more paging
activity.
It reduces the size of the buffer cache,
meaning that files outside the set you've placed
in RAM are more likely not cached. This also
includes filesystem metadata, such as block
bitmaps and the like.
Even if the Linux ramdisk can be swapped out
(I think the new ramfs may be capable
of this), it will still likely be slower than
a traditional filesystem if you push into swap,
because swap gets fragmented over time.
In contrast,
ext2 resists fragmentation pretty well
and so will perform better as a result.
Where can I find it? And how fast is it compared
to a plain xterm? One of the reasons
I hate ETerm is that screen refreshes are SO FLICKERY SLOW, even if I shut off the background
pixmap. xterms are pretty snappy by comparison.
Mac, Windows, VMS, MVS, Amiga, et.al all do direct and/or syncronous writes to the disks.
I can't comment intelligently on Mac, VMS, MVS
or Amiga, but I can say that Windows does permit
a write-behind cache. (Or at least, some
versions of SmartDrive provided a write-behind
cache.) The problem was, though, that DOS or
Windows would often crash with dirty blocks
still in the cache, and you'd end up with a
toasted FAT or whatever. So, around DOS 6.2
timeframe, MS changed the default to "write-behind off."
Uhm, see, "5" is where Intel switched from using numbers to using the name "Pentium". So, by that
logic, "Pentium 5" should be "Pentium Pentium".
And the rest follows from there.
Folks, get it right. Moore's Law simply states
that the number of transisitors on a chip doubles
every N months, where N = 24 in the first statement of the "law",
and was revised shortly thereafter to N = 18.
Typically, performance scales with number of transistors, but that is not always true!
There are three main reasons performance does go up roughly by the same ratio
as the number of transistors:
Some of those transistors can be used for new functions. For example, additional functional units (such as the three-way issue pipeline on PentiumPro/PentiumII vs. the U-pipe and V-pipe on Pentium vs. the single-issue pipe on 486). This is a direct application of transistors to performance, but it only addresses computation-bottlenecked applications. Additionally, some of those transistors can be used to build wider pathways on the chip, leading to improved bandwidth to help bandwidth-starved applications.
Smaller transistors switch faster, and so can operate at higher clock rates. This has the dual effect of increasing the number of computations per second (again helping compute-bottlenecked applications), as well as increasing bandwidth--at least on the die. Going off-chip can still be a bottleneck. That brings us to the third bullet:
Smaller transistors can be used to build a bigger cache, so that the clock rate and on-chip bandwidth benefits can be used to greater effect.
Sounds great, but what's bad?
Well, one big
thing that is not addressed by faster
transistors is latency. As transistors get
smaller and the wires that connect them get smaller, communication between transistors
starts to become the true bottleneck. In the
"Good Old Days", you could send a signal anywhere
on the die in a single cycle, and you could treat
a wire as an instantaneous link. In these
smaller technologies, though, transport time for signals burns a significant portion of the time for any computation. This is why pipelines get
deeper and deeper with each generation. Essentially, you can only make effective use of
all of those transistors if you can minimize the amount of communcation between them, and that's what pipelining is all about. Unfortunately, this limits how much you can speed
up many applications, especially general-purpose
compute problems.
Newer architectures address latency problems
by exposing their pipeline (see EPIC or VLIW), or providing extensive resources for dealing with it. The Alpha CPUs,
for instance, have an aggressive cache and reorder buffer that allow many pending cache misses to be services while non-dependent instructions are executed happily. (IIRC, the 21264 allows up to 4 hits under miss in the cache -- that is, you can
have up to four misses outstanding and still take hits in the cache and allow instruction execution to proceed. I don't have Hennessey and Patterson handy to check though.) The reason this is even conceivable is that the Alpha provides a huge bank of architecturally-visible registers, and an even larger bank of rename registers for rescheduling code. Since compiled code spends
most of its time moving data between registers,
the architecture can easily determine which instructions are dependent on each other and very effectively hide the
latency of the pipeline by reordering instructions
and renaming registers.
In contrast, the x86's highly bizarre and rather
small register file create a huge bottleneck to
reordering, since compiler ends up spilling many
intermediate values to the stack or other memory
locations. As a result, the CPU can't use register names to determine instruction dependencies as often, and so it cannot aggressively reorder instructions. As a result,
it cannot hide the latency in the pipeline as effectively, and
gets bitten with poor performance. All those
transistors sit idle more often. (This, BTW,
is why the Alpha can beat the Athlon on some
apps, despite a 2x clock-speed advantage on
the Athlon's part.)
There are plenty of other reasons why x86 can't
keep up performance-wise, but this is not the
forum to discuss them. Just remember, x86 is
keeping up with Moore's Law just fine. Don't
expect its performance to keep scaling at the
same rate.
So much for my 300 Watt halogen "TorchAire"
lamps... Shoulda figured those imported lamps
may not be 100% compatible w/ U.S. electrical
standards.
Seriously, 130W of power is nothing compared to,
say, your average hair dryer, many of which run at about
10x that wattage. Or a typical microwave oven, operating in the 700W to 1000W range. Even your typical desktop computer
system, including monitor, etc. consumes 600W to
800W if you're not running w/ any APM options
enabled. (Remember, a 250W power supply provides
250W to the rest of the computer, but consumes
some additional wattage itself. Although switching power supplies are fairly efficient,
no power supply is 100% efficient.)
The UNIX® system is optimized for footprint (it originally ran in 1 MB machines IIRC).
Actually, I believe in the Version 6 era, it
ran on machines with ~64K of memory.
The GNU system, OTOH, is optimized for speed. This "use more RAM if it'll improve performance
and/or simplicity" mentality helps counter copyright infringement allegations by UNIX system vendors against GNU system developers who have never read UNIX system code.
The GNU system is actually built around "no arbitrary limits." Go read the man-page for tail on a SunOS machine (ok, those are
rare these days, but not so rare at the time I
learned UNIX®),
and it'll say something about lines being
limited to 1024 characters or thereabouts. GNU saw that the functionality provided by the UNIX® toolset was desirable and the mindset of "a sharp tool for each task" was powerful, but also saw
that arbitrary limits really dulled UNIX®'s blade.
Therefore, as the limitations imposed by small memory and expensive CPU were no longer present, GNU optimized their efforts for flexibility rather than size.
I'd say it was the "right way" in many ways, although the featuritis in some programs has served to dull GNUs blade in other ways.
Right, but a large proportion of the 'Doze
world barely knows how to start Microsoft
Word w/out clicking on a Word document directly,
let alone fire up a debugger. Cheats and cracks
help out the tech-saavy users, but the bulk of
the $$ come from people who know just enough
to be dangerous.
I've cracked a few copy-protection schemes myself.
But still, I'm usually the one in my family which sets up the computers and stuff for everyone else, while most everyone else in the family knows
a a handful of cookbook operations, such as
how to click on "Connect to the Internet".
But it would be useless to the physician end-user. We are lucky in that our CEO and many of the top dogs are in fact physicians. Those that aren't are in daily contact with physicians
and nurses and hospital admins. If the majority of the users want a feature, we will do that feature, regardless of what the engineers think. This is a Good Thing!
Be careful here. There is a distinct difference between what a customer needs, and what the customer thinks they need. When a customer comes to you requesting feature X, you, as a developer, should ask for the larger context that X fits into, and the larger need that's being filled. Perhaps X is difficult to implement and fits the need in a narrow fashion, but a different solution Y would fill the need better and may be easier to implement.
Really, the specification process needs to be a two-way street between the developers and the customers, so that the developers produce something truly useful for the customers, and the customers ensure their needs are met.
Slashdot Mirror
Naw... Un-nil-hexium Visa! (You know, w/ the 1.06% APR... ;-)
--Joe--
Lessee ... about the same thing that happens
when I do it as a mortal user. I get some
messages in the system logs about how it couldn't
read a particular sector, and that's about it.
Sometimes I get my file, but (depending on the
damage), usually I do not. Of course, I've been
reading heavily damaged disks this way. :-)
--Joe--
That reminds me, I came across Stephen Hawking's Gansta Rap page the other day. Maybe he should add a new verse to F*** the Creationists...
--JoeP.S. It's spelled (+1, Funny).
--
This lawyer does, I personally don't, for much the same reasons as you mention it. The lawyer is merely pointing out that "See, we managed to ignore the (possibly valid and quite important) criticisms in the gene-patent debate, so there's a precedent." (Obviously, I'm characterizing it quite a bit differently than he would have me characterize it.)
--Joe--
True, and I'd forgotten that. Just don't go on vacations w/out your email then. ;-)
--Joe--
This way of arguing really slants things. The general form is devious: "Some have criticized [insert reasonable criticism here]. Some of this criticism comes from [insert more radical elements of the larger critiquing community here]. Similar kinds of criticisms were raised in [some other situation in which we ignored the criticisms]". The basic idea is to invalidate the criticisms by saying "yeah, but some of them come from really out-there people, and see, we've ignored this stuff before!" It's kinda like guilt by association. "If you agree with these criticisms, then you must be in this group over here which is at one extreme."
No sir, I don't like it.
--Joe--
And I suppose you like getting random pizzas at 3AM? If someone happens to get a copy of your Amazon 1-click cookie (whether via a browser exploit, email/Word macro trojan, sniffing network traffic, whatever), then they can make life very annoying for you very, very easily.
Imagine if they sent a dozen different books a day to you over a 1 week period. Do you really want to deal with ~100 books arriving and having to send them all back? Much more annoying than prank pizza delivery.
Sure, that's just the pranksters, but its still not something I'd like to have happen to me.
--Joe--
Yup. Simple traceback. Plain and simple. For each cell, move in the opposite direction from the direction I moved to enter this cell. Record the original movement in reverse order in the answer buffer.
BTW, I sent you a better-documented version just now. I realized that "ixyp" and "oxyp" aren't real nice names for variables, unless you realize I mentally read "input x/y coordinate pointer" and "output x/y coordinate pointer". More directly, in the context of a queue, these are "head" and "tail". :-)
--Joe--
Funny you should say that. In an email I just sent you (before I read your post), I highlighted a similar gem of my own doing:
do { *--s = "DLRU"[m]; mp -= dm[m]; } while ((m = *mp) != 'S');
Cool, eh?
--Joe--
Actually, I think that very often when I look at my own code. I don't smoke in the traditional sense, though. The most that happens is that smoke starts curling out of my ears after a few Venti coffees from the local Starbucks.
The kind of coding I do, though, is prone to these sorts of questions. :-)
And yes, it's supposed to look like that.
--Joe--
According to an email I got from CowboyNeal, it's actually 50. I asked after my karma dropped by 2 after having two articles modded up to +3 and +5, and another couple modded down. The net should've been positive, but it was negative due to the cap.
--Joe--
I never said it's a great idea. It's a horrible idea if you want good performance and a stable (as in "not crashing") platform. It's a wonderfully pragmatic idea, though, if you want to move billions of existing lines of code to a new platform without (much needed) rewriting, though.
That's fine. That's what sells in the high-end gaming market, anyway. Look at the "64-bit" videogame systems.
--Joe--
I'm pretty sure he meant an in-place filesystem conversion utility. You can convert an ext2 filesystem into an ext3 filesystem in-place. The same cannot be said for ext2 to any of the other filesystems.
--Joe--
The IA-64 does not execute IA-32 via software emulation. They do have IA-32 instruction decoders on the die.
The main issue is that IA-32 vs. IA-64 is modal, and so you can't mix the 64-bit and 32-bit code with a very fine granularity. From what I understand, it the mode-switch was meant to be thrown with about the same granularity as a context switch.
Sledgehammer, on the other hand, sounds like it's trying to be a straight extension on IA-32, and so would layer over IA-32 much like IA-32 layered over the 80286, which layered over the 8086... This would allow 32-bit and 64-bit code to mingle within an application. (Just look at Windows 9x for an example of a deployed system that operates in this manner, and why Sledgehammer might hit where Itanium misses.)
And one last thing: Itanium is the collective name for the IA-64 platform, whether it's Merced or McKinley, just as Pentium has become the name for the current set of IA-32 chips. Merced might get cancelled, leaving McKinley as the first Itanium chip to ship. Wouldn't surprise me in the least.
--Joe--
They didn't want to get sued. After all, MP3's are illegal and are only used by hackers, right?
*cough* *cough*
--Joe--
You're partly right. The other reason is that it forces more pages out to swap, since the RAM disk can't be paged out (I'm pretty sure). Placing your data in a traditional Linux RAM disk has two bad effects:
Even if the Linux ramdisk can be swapped out (I think the new ramfs may be capable of this), it will still likely be slower than a traditional filesystem if you push into swap, because swap gets fragmented over time. In contrast, ext2 resists fragmentation pretty well and so will perform better as a result.
My 0x02 cents...
--Joe--
Where can I find it? And how fast is it compared to a plain xterm? One of the reasons I hate ETerm is that screen refreshes are SO FLICKERY SLOW, even if I shut off the background pixmap. xterms are pretty snappy by comparison.
--Joe--
--
Uhm, see, "5" is where Intel switched from using numbers to using the name "Pentium". So, by that logic, "Pentium 5" should be "Pentium Pentium". And the rest follows from there.
Now do you get it?
Laugh, then.
--Joe--
Folks, get it right. Moore's Law simply states that the number of transisitors on a chip doubles every N months, where N = 24 in the first statement of the "law", and was revised shortly thereafter to N = 18 .
Typically, performance scales with number of transistors, but that is not always true! There are three main reasons performance does go up roughly by the same ratio as the number of transistors:
Sounds great, but what's bad?
Well, one big thing that is not addressed by faster transistors is latency. As transistors get smaller and the wires that connect them get smaller, communication between transistors starts to become the true bottleneck. In the "Good Old Days", you could send a signal anywhere on the die in a single cycle, and you could treat a wire as an instantaneous link. In these smaller technologies, though, transport time for signals burns a significant portion of the time for any computation. This is why pipelines get deeper and deeper with each generation. Essentially, you can only make effective use of all of those transistors if you can minimize the amount of communcation between them, and that's what pipelining is all about. Unfortunately, this limits how much you can speed up many applications, especially general-purpose compute problems.
Newer architectures address latency problems by exposing their pipeline (see EPIC or VLIW), or providing extensive resources for dealing with it. The Alpha CPUs, for instance, have an aggressive cache and reorder buffer that allow many pending cache misses to be services while non-dependent instructions are executed happily. (IIRC, the 21264 allows up to 4 hits under miss in the cache -- that is, you can have up to four misses outstanding and still take hits in the cache and allow instruction execution to proceed. I don't have Hennessey and Patterson handy to check though.) The reason this is even conceivable is that the Alpha provides a huge bank of architecturally-visible registers, and an even larger bank of rename registers for rescheduling code. Since compiled code spends most of its time moving data between registers, the architecture can easily determine which instructions are dependent on each other and very effectively hide the latency of the pipeline by reordering instructions and renaming registers.
In contrast, the x86's highly bizarre and rather small register file create a huge bottleneck to reordering, since compiler ends up spilling many intermediate values to the stack or other memory locations. As a result, the CPU can't use register names to determine instruction dependencies as often, and so it cannot aggressively reorder instructions. As a result, it cannot hide the latency in the pipeline as effectively, and gets bitten with poor performance. All those transistors sit idle more often. (This, BTW, is why the Alpha can beat the Athlon on some apps, despite a 2x clock-speed advantage on the Athlon's part.)
There are plenty of other reasons why x86 can't keep up performance-wise, but this is not the forum to discuss them. Just remember, x86 is keeping up with Moore's Law just fine. Don't expect its performance to keep scaling at the same rate.
--Joe--
So much for my 300 Watt halogen "TorchAire" lamps... Shoulda figured those imported lamps may not be 100% compatible w/ U.S. electrical standards.
Seriously, 130W of power is nothing compared to, say, your average hair dryer, many of which run at about 10x that wattage. Or a typical microwave oven, operating in the 700W to 1000W range. Even your typical desktop computer system, including monitor, etc. consumes 600W to 800W if you're not running w/ any APM options enabled. (Remember, a 250W power supply provides 250W to the rest of the computer, but consumes some additional wattage itself. Although switching power supplies are fairly efficient, no power supply is 100% efficient.)
--Joe--
Got that?
--Joe--
Actually, I believe in the Version 6 era, it ran on machines with ~64K of memory.
The GNU system is actually built around "no arbitrary limits." Go read the man-page for tail on a SunOS machine (ok, those are rare these days, but not so rare at the time I learned UNIX®), and it'll say something about lines being limited to 1024 characters or thereabouts. GNU saw that the functionality provided by the UNIX® toolset was desirable and the mindset of "a sharp tool for each task" was powerful, but also saw that arbitrary limits really dulled UNIX®'s blade. Therefore, as the limitations imposed by small memory and expensive CPU were no longer present, GNU optimized their efforts for flexibility rather than size.
I'd say it was the "right way" in many ways, although the featuritis in some programs has served to dull GNUs blade in other ways.
--Joe--
Right, but a large proportion of the 'Doze world barely knows how to start Microsoft Word w/out clicking on a Word document directly, let alone fire up a debugger. Cheats and cracks help out the tech-saavy users, but the bulk of the $$ come from people who know just enough to be dangerous.
I've cracked a few copy-protection schemes myself. But still, I'm usually the one in my family which sets up the computers and stuff for everyone else, while most everyone else in the family knows a a handful of cookbook operations, such as how to click on "Connect to the Internet".
--Joe--
Be careful here. There is a distinct difference between what a customer needs, and what the customer thinks they need. When a customer comes to you requesting feature X , you, as a developer, should ask for the larger context that X fits into, and the larger need that's being filled. Perhaps X is difficult to implement and fits the need in a narrow fashion, but a different solution Y would fill the need better and may be easier to implement.
Really, the specification process needs to be a two-way street between the developers and the customers, so that the developers produce something truly useful for the customers, and the customers ensure their needs are met.
--Joe--