Actually, there was a post awhile back (on Bugtraq, if I recall correctly), showing that a couple popular models of answering machines had very, very small code-spaces.
IIRC, the particular models I have in mind had code-spaces of 8 and 16 codes for the 2 and 3 digit models, respectively.
I know on one of mine, it just looked at the 'column' tone pattern. So, '737' is equivalent to '191', etc... *shudder Imagine what sorts of sensitive items could be on there...
"Hello, this is SuburBank calling about your MisterCharge account 4121 3242 5323 6171....."
Actually, Kirk McKusick, Bill Joy, Jordan Hubbard, Theo DeRaadt and Mike Karels are all on the list, at least when I last checked. (Maybe GNU added them?)
Personally, though, I'd like to vote for W. Richard Stevens, in memory of his great books.
It's a touchy subject, since there's a fine line between expressing interest and sexual harassment. Where I work, we have very strict sexual harassment policies. However, I know of two married couples in our group alone, and a pair of friends that may become a couple pretty soon. All of these are coworkers.
The main restriction our employer puts on us is that one of the spouses can not be the other's superior on a reporting chain. (eg. you can't marry your manager or your manager's manager.) Other than that, you're ok.
My suggestion: Start small -- "Hey, want to go to Starbucks to grab a cup of coffee?" -- and if things seem to click, build up a little. If the person you're interested in seems to back away or not be interested, back off somewhat, but don't alienate them (particularly if they're in your workgroup). Alienation is just as much sexual harassment as overattentiveness.
Welcome to the millenial workplace, where morale and loyalty are low, tension and stress are high, and legal pitfalls abound.
Well, she certainly looks like one in her picture, and an attractive one at that. (Even more attractive when you consider she's into computers and reads Slashdot.) And no, I'm not providing a link for all you HNG's. (Yes, I realize that could be a picture of someone else, but what would be the point of getting worked up on conspiracy theories?)
I guess you can tell what type I go for, when you consider that my fiancee meets many of the same 'attractiveness' critereon.:-)
I think you confuse some issues. Alladin has had _two_ business models. The old was to use GPL and sell exceptions. The new is to use a more restrictive license for new versions, sell exceptions, and release old versions under the GPL.
Point taken. Thank you for the clarification on this part. I'm more familiar with their current business model than with their previous.
I'm not sure I buy the "Postscript-enabled Proprietary Applications" argument, though. What's to stop these app developers from providing support for some other common interface (say PPM) and saying to people, "Hey, you can get Postscript support really easy by doing this:..."
Namesys will not need to change their license, because their potential customers will not be able to use a similar loophole.
I'm not sure I follow. What happens when Mfgr X builds up some proprietary system which needs the reliability of ReiserFS, and ships it along with a Linux kernel source tarball containing ReiserFS? If the ReiserFS itself is an integral part of the product (say, for reliability reasons or whatever), then how is this any different from the Ghostscript case you mention? If Namesys is counting on charging all commercial customers, then this doesn't work. I doubt they are, though.
One possible application I can think of that falls in this category is a Point-of-Sale system. I can imagine the folks implementing these systems needing reliability as well as the recovery aspects that ReiserFS provides. At the same time, the POS software itself is highly proprietary, and is using the filesystem as a client. Say WhizBang POS Systems starts shipping their proprietary, binary-only POS software on a CD with the Linux kernel and ReiserFS patches installed. For GPL compliance, they have a big source tarball containing Linux+ReiserFS. How is this different from the Ghostscript scenario you described?
The availability of GPL exceptions is more likely to affect people with closed OSes, or OSes whose license is not GPL compatible. (eg. QNX, the BSDs, other embeddeded and commercial OSes.) For instance, suppose I want to integrate ReiserFS into a DSP design running SPOX. I would need to license ReiserFS for that application. I suspect that is the crowd that these license exceptions are aimed at -- it's not the same story as for Ghostscript.
Or did I miss something?
(PS. I'm not trying to be antagonistic or anything. I find this to be an interesting and enlightening discussion, and I'm truly trying to understand the subtleties.)
RMS had no problems with this business model, . . .
Actually, I hear that he's not thrilled with it. Indeed, one of the biggest problems that I can see is that there is very little incentive for people to improve the existing GPL version of Ghostscript when they know that Aladdin has (a) already improved Ghostscript in the current commercial version, and (b) will be releasing their changes 'soon' (after one year). This interview with Ghostscript's author Peter Deutsch sheds more light on the situation, including Stallman's thoughts.
One result is that the GPL community is almost guaranteed to always be one year behind the latest in Ghostscript technology, unless someone gets up enough nerve to fork Ghostscript development and try to get ahead of Aladdin.
With Ghostscript the GPL was not restrictive enough. Proprietary software would simply call the gs executable in a separate process.
Part of the problem here is that the Aladdin folks try to license their code to printer manufacturers, etc. The printer folks aren't too keen on having to ship Ghostscript on demand to anyone who buys a printer. Also, if the printer folks make any platform specific changes (which undoubtedly they will, such as specific driver technology for running the print engine), they'd have to distribute those changes, and most aren't willing to do so.
Also, more importantly, Peter Deutsch doesn't seem too keen on having people ship Postscript-enabled printers by using his work for free (as in gratis).
The upshot: Aladdin offers their latest and greatest Ghostscript with a commercial license.
With ReiserFS, I'm sure a similar but not identical set of considerations exist. People building embedded or mission critical systems on an otherwise proprietary base might license ReiserFS for their application without introducing any questions as to the effects of GPL. At the same time, a GPL version is available for everyone.
The difference here is a bit subtle but important. Namesys appears to be releasing the latest and greatest ReiserFS under GPL, rather than imposing an artificial delay. (Whether or not this changes in the future is unclear, but for now it is an important distinction.) In this case, the commercial license seems to be a means for companies to buy an "unencumbered" version of ReiserFS for their own purposes. (By "unencumbered", I mean free of the implications of GPL.) I see this potentially as a way to keep both camps happy. Maybe. (Except, of course, RMS.)
Isn't it somewhat interesting that no more than a year ago, Linux had no journalling filesystems. Then everyone complained. Now we're going to have three journalling filesystems! (XFS, ReiserFS, and ext3) If anyone cares to complain about the lack of responsiveness of the free software community, I suggest you take a look at this.;-)
I guess good things come in threes?
Heh, I just happened to think, there's a few other places the "good things come in threes" applies:
There are three free BSDs: NetBSD, OpenBSD and FreeBSD.
There are three widely available X servers for Linux (that I'm aware of) -- XFree86, MetroX, Accelerated-X.
Back in the Linux 0.99 days, the recommendation was to "sync three times and then shutdown."
You could boot from an initrd RAM Disk, load the XFS module, and then remount your root partition from an XFS partition on your hard-drive. After all, this is how RedHat kernels allow you to have your root partition on a SCSI drive, yet still have all of the SCSI devices built as modules.
Indeed, just this sort of technique can also be used to handle a ReiserFS root partition that needs to be fsck'd, by having the boot routines in the RAM disk image do the fsck if necessary. Strikes me as a bit more fragile than what I'd care to deploy in a mission critical setting, but....
Linux may not be an official Unix, but it is good for Unix. That alone makes it an important event in Unix history.
It's important in the same way IBM PC clones were important to IBM. They weren't IBM PCs, but the fact that they were compatible and completely changed IBM's impact on the world was fairly relevant. Linux seems to be having a similar effect with respect to Unix.
BTW, who remembers the rest of the tunefs joke? (Namely, the bits that were in the actual nroff source for the man page?)
From what I recall, the man page's source said something along the lines of "Remove this, and a Unix daemon will dog your steps until the time_t's wrap around." I unfortunately do not have access to a system with the original quote that I know of offhand. Anyone?
As the AC above noted, C's default assuptions about pointer aliasing make certain classes of programs run like crap. The new restrict keyword is a huge step in the right direction, but it's still a Band-Aid.
Why are sane pointer aliasing conventions important in the language? Well, since effecient code generation is something nearly everyone lusts after, compiler writers spend alot of effort "optimizing" code. Since C doesn't provide much of a mechanism for describing where pointers point, the compiler has to implement alot of guesswork. If it's not sure, it punts and outputs slow code.
The problem is that these optimizations are hard to get right. Notice how GCC 2.95 broke the Linux kernel, unless you compiled with the new alias analysis turned off. It would be better for the language to have saner pointer semantics.
Note that this wasn't so much of a problem in the beginning when pipelines were short and issue-widths were narrow. Nowadays, though, pointer aliasing issues are one of the biggest issues preventing code from going faster. (I know, I hit these issues regularly.) I welcome restrict with open arms.
--Joe --
Re:'c' isn't the problem. Transmission line delay
on
Pentium III hits 1Ghz
·
· Score: 1
I stand corrected. The main point is still valid: Copper is faster because RC went down. Instead of R being less, it sounds like it was C. Thanks for the info!:-)
It's not just ASCII that's the issue. The problem is that humans tend to manipulate dates as 2-digit quantities. Y2K bugs happen all over the place regardless of what the internal representation is.
For instance, one case that shows up on POSIX systems is misuse of tm_year in struct tm. A common Y2K mistake: printf("Year: 19%02d\n", tm->tm_year);
One place I found a Y2K bug similar to this was in the Intellivision's EXEC ROM. The cartridge header stores the copyright year in a 10-bit field. (The year is given in years after 1900, so 1978 would be stored as the number 78). 10 bits is enough to go all the way to 2923, but the display code which displays the copyright hardcodes the '19' in front of the date and prints garbage for the third digit. The sad irony is that the EXEC does include routines for printing the whole 4-digit date properly. Nothing ASCII-specific about that.
On BCD (Binary-Coded Decimal) systems, storing a two-digit date in a byte was common. BCD-based systems are popular in banks and other financial settings due to the fact that BCD provides exact rounding for a decimal numeric representation. Again, non-ASCII. These bugs hit more of the ancient COBOL code than anything, though.
Other places Y2K problems show up are in forms and other places where humans are expected to enter dates. If the forms are designed to accept two characters for the year, then the software must assign some policy for picking the century. Different software has different policies, leading to all sorts of problems.
BTW, as long as I'm being nit-picky, the statement "pi == 3" is very accurate. It's just not terribly precise.
Bear in mind DPCE was based on Thinking Machines' C* language. The Thinking Machines boxes could have up to 65536 CPUs, and so it's reasonable to expect C* could generate code to make use of that. What's nice is that the programmer still writes in nice, linear code. The explicit loops they had to write before to do, say, a matrix multiplication, now become simple math operations. The compiler can then parallelize as it sees fit. The programmer actually sees nice linear code which is actually simpler than the looping code which he would've written before.
The people who want major parallelism (and can actually benefit from it) are numeric processing goons running weather simulations and other large number processing that is the traditional province of supercomputers. The other space where it is useful is in signal processing and graphics. The desktop crowd isn't going to care much, unless the parallelism gives them an extra frame per second in Quake III.:-)
As for knowing multiple paradigms: Yes, it's useful, just like learning foreign languages is beneficial, even if it only serves to help you understand your native tongue better. The problem is that not all programming paradigms are immediately useful to the task at hand, so many of us just don't have the time or inclination to get around to it. (I fall into this category.)
Awhile back, the X3J11 group responsible for the ANSI C standard was looking at some rather nifty data-parallel C extensions that retained the otherwise "serial programming" nature of the control code. I suspect that an evolutionary approach such as this is likely to gain more ground than forcing people to think about programming in a completely different paradigm.
'c' isn't the problem. Transmission line delay is.
on
Pentium III hits 1Ghz
·
· Score: 2
That pesky constant 'c' must be holding back faster CPUs by now.
Not exactly, but close. Signal propogation delay is getting worse and worse with respect to clock cycle. In the early days, you could consider wire to have zero delay, since transistors were so slow compared to the propogation rate on the wire. As wires have gotten smaller and smaller, their resistance has gone up. Meanwhile we've packed them closer and closer together, so we have tons of capacitance between wires. And finally, transistors have gotten orders of magnitudes faster.
End result: It takes bloody ages for a signal to get anywhere on the chip with respect to how long it took to generate the signal.
Most pieces of silicon nowadays operate with various "domains", each of which has its own local clocking. Depending on how fast you're running, it can take several clocks just for a signal to travel from one end of the chip to the other, so designers tend to subdivide problems into domains that aren't more than a clock-cycle wide. Pipelines and replicated hardware help a little, but physics really starts to bite you in the arse. Copper helps a little here (since it lowers resistance), but it's not a cure-all either.
Our friendly constant 'c' is a couple orders of magnitude above the propogation rate on the chip, so it's not the main limiter. To put it into perspective, light travels 30cm every nanosecond, and chip dimensions are usually closer to 1cm on a side. But we're getting uncomfortably close.:-)
x86 chips are actually quite efficient in terms of ops/cycle.
No, they're not.
For example, loading a 32-bit immediate value to a register takes one cycle on a pentium or K6, but on a MIPS RISC cpu for example takes 2 instructions and 2 cycles due to the smaller instruction size.
So? Generating 32-bit constants is not what interesting programs spend most of their time doing. Optimize the common case.
The problem is that the complex instruction decoders use a lot of power.
To sum it up, I'd have to disagree on several points:
Complex instruction decoders are a bottleneck to issuing large numbers of parallel instructions. It's more than just a power issue.
The 32-bit constant generation example you have is not a typical bottleneck in most code. Control flow is more likely to be.
x86 is less efficient than alot of other machines due to being a register-starved architecture. It has to rely on tricks such as store-to-load forwarding and micro-caches to turn a small cache of memory addresses into a pseudo-register file.
While Intel has generally been the "Floating Point King" in x86 world (with Athlon recently taking the title away), x86 floating point as always sucked compared to architectures that have traditionally taken FP seriously. RISC wins squarely here, period.
*sigh* Not only do we have the usual cliches about patenting everything in sight (Stop breathing: You're infringing on patents 5,678,910 and 5,789,012), but also we have the (nowadays untrue) reiteration that the Y2K bug happened because programmers wanted to save a byte or two. When does this nonesense stop?
The Y2K bug happened because people window dates already. It of course seems absurd to patent the cause as the cure. The reason computers process dates with two-digit years is that humans process dates as two digit years. Twenty to thirty years ago, those two digits might have meant something in terms of storage, and yes, there is legacy COBOL code that is that old which exhibits the bug for that reason. Nowadays, those bytes are nothing, and the Y2K bug in modern software is mainly due to sloppy human custom being poorly translated to computer form.
Using two-digit years is a long-standing human practice, and let's face it, it's pretty arbitrary how we handle them. Humans generally have a pretty good sense of context, and I doubt machines will ever match it. Nonetheless, even humans can (and do) get tripped up.
Most of the ghosts look more like JPEG artifacts (eg. ringing and smoothing) than actual ghosts. To make this a serious endeavor, they need to take the IR filter off the camera and set the JPEG quality factor to maximum.
The rest look like they were done in Photoshop. One of them has such sharp lines on the "blurry ghost area" that it seems to be a rather obvious fake. (If the blurry area were that sharply delineated in real life, then there would've been more artifacts in the JPEG.)
Given the nature of it all, this looks more like a PR stunt than anything else. Welcome to the Web 1999!
The whole "fair"/"unfair" bit doesn't work well for me, either. I'd rather M2 work more like this:
Include the parent and response posts via a link named "context". That way you could open a link in a new browser window to find the context of the post.
Rather than ask "fair" or "unfair", ask the meta-moderator how they would have moderated the comment given the conditions that were present at the time it was moderated the first time, and use that to judge the moderation that was actually performed. The slash-engine could then use the M2 totals to judge the quality of the M1 moderations that were performed.
For example, suppose this comment got moderated up once as Insightful and at about the same time got moderated up as Informative, and later got moderated down as Overrated. Depending on your frame of mind, all three moderations could be reasonable. (Particularly if the two +1 moderations came in about the same time such that the moderators didn't see each others' moderation. There's an inherent race condition in moderation.)
Now suppose the M2 page for three different users show one of the three moderations. In each case, it will show the state of the comment at the time it was moderated. (Perhaps, in light of the race condition mentioned above, it might be better to show the state of the comment as the original Moderator saw it, since two people could moderate the same comment without seeing each others' moderations ahead of time. It's not their fault that they don't automatically reload everytime someone else moderates.)
User 1 might see the first moderation's starting state: "Score: 1". User 1 gets to pick how they would've moderated the comment, given that starting score. Assuming they pick a moderation that's at least somewhat aligned with the Insightful moderation that was actually applied, then the moderator's karma goes up. If User 1 picks a moderation which may be in the same +1 direction, but is semantically completely different (eg. Funny), then the effect is neutral. If User 1 picks a moderation which is semantically similar but in the opposite direction (say, "Troll"), then the effect is negative on the original moderator's Karma.
User 2 gets a similar scenario, only they're presented with the post showing an original score of 2. (Or, if the race condition I mentioned above existed at the time of moderation, it too would show "Score: 1".) Their input is compared against the second moderation that was performed, namely, the Informative moderation. The same process applies.
In any case, User 3 would get to see the "Score: 3" initial state, and their response would be compared to the Overrated moderation.
The end result is that the semantic issue is abstracted away. Rob and company can decide how sematically similar Informative is to Insightful when they build the correlation lookup table. I'm guessing all "positive" moderations are at least loosely tied together (maybe a factor of 0.25, if you treat identical moderations as 1.0 correlation -- slightly more for the generic "Underrated" vs. the rest). Same story for the negatives.
At any rate, I don't think it ever really makes sense to call a particular act of moderation "fair" or "unfair", particularly if the comment was being marked with a postive moderation. Perhaps "appropriate" or "inappropriate" work better than "fair" or "unfair."
Sites that require free registration do so for only one reason: they want a mailing list.
A mailing list is only part of it, and often not a very big part of it. In the case of the New York Times, they don't seem to use your email address for much, if anything.
Rather, they're interested in demographic information, including whether or not you're willing to provide valid information on the form. Knowing their typical audience (eg. income bracket, etc.) as well as their willingness to provide such information gives them some powerful tools for better targeting their site (both articles and advertisements) at the readership.
If you use the same user-id each time, they also can build up statistics on readership patterns. This is likely why they have the "Save this ID on my machine" checkbox, in order to encourage this sort of consistent tracking.
Building a spam list which alienates readers is probably pretty low on their priority list right now.
For the people who accidentally click [Submit] twice and so on, could we have a "Suppress Post" button that users could use on their own posts? It'd put move the post to a score of -1 (or maybe even -2) immediately and would allow people a chance to clean up embarassing mistakes without completely sweeping them under the rug.
To prevent abuse, you might want to tie a -1 karma to the feature. Otherwise people might just stop using [Preview] altogether, or might start posting "guerrilla posts" -- posting something inflammatory, and then suppressing it before the moderators hit them. The -1 karma is much smaller than the 2 or 3 "Redundant" moderations, but is a large enough disincentive to prevent abuse, I think.
At any rate, it'll provide a way for posters to clean up after themselves.
When a user hits "Reply To" please quote the parent message back to the user for referance.
Actually, it already does that when I hit reply (except that the parent message is quoted above rather than below. Minor detail -- either way works.) How is yours configured?
As long as we're talking about the Reply page, is there any way we can get wider text boxes? I hate typing in these little tiny portals on the screen. Maybe make it configurable on the user page, so that the crowd using 1600x1200 with a flyspec-3 font can coexist with the crowd using 640x480 and a courier-24 font?
Also, could you escape out & symbols, replacing them with & when constructing the default text in the comment box for "Preview Mode"? That'll make all of the &symb; style symbols work properly when clicking Preview. (Right now, I kluge around it by hitting Back after a Preview so I don't have to hunt for all the &symb; symbols embedded in my comment.)
There are some things they can do to increase their latency.
I think you mean improve rather than increase. A gamer's modem should have low latency, because high round trip times are bad for interactive response.
You are right though in your basic premise: There are various tricks the modem folks can pull to speed up modems. Probably the most effective trick would be to recognize IP/PPP/SLIP packet boundaries and use those as the quanta for compressing/error correcting, rather than the current "dumb wait" that modems currently do. (This was mentioned in an article linked elsewhere in comments.) Another would be to disable compression entirely for games, since it doesn't help much anyway -- the packets are too small.
As for analog vs. digital latency: The POTS network (POTS == Plain Old Telephone Service) is mostly digital anyway. The analog line you have in your home is usually converted to digital fairly quickly. The D/A in your modem coupled with the A/D in the POTS network do add some latency, typically equal to a couple sampling periods. At 8000 Hz, that would amount to around 1ms, if you assume a total of 8 sampling periods worth of conversion time and buffering.
Slashdot Mirror
Actually, there was a post awhile back (on Bugtraq, if I recall correctly), showing that a couple popular models of answering machines had very, very small code-spaces.
IIRC, the particular models I have in mind had code-spaces of 8 and 16 codes for the 2 and 3 digit models, respectively.
I know on one of mine, it just looked at the 'column' tone pattern. So, '737' is equivalent to '191', etc... *shudder Imagine what sorts of sensitive items could be on there...
--Joe--
Ah, ok... I had read your original post as "I['d] really like [to] see", rather than "I really like see[ing]". Oops. :-)
--Joe--
Actually, Kirk McKusick, Bill Joy, Jordan Hubbard, Theo DeRaadt and Mike Karels are all on the list, at least when I last checked. (Maybe GNU added them?)
Personally, though, I'd like to vote for W. Richard Stevens, in memory of his great books.
--Joe--
It's a touchy subject, since there's a fine line between expressing interest and sexual harassment. Where I work, we have very strict sexual harassment policies. However, I know of two married couples in our group alone, and a pair of friends that may become a couple pretty soon. All of these are coworkers.
The main restriction our employer puts on us is that one of the spouses can not be the other's superior on a reporting chain. (eg. you can't marry your manager or your manager's manager.) Other than that, you're ok.
My suggestion: Start small -- "Hey, want to go to Starbucks to grab a cup of coffee?" -- and if things seem to click, build up a little. If the person you're interested in seems to back away or not be interested, back off somewhat, but don't alienate them (particularly if they're in your workgroup). Alienation is just as much sexual harassment as overattentiveness.
Welcome to the millenial workplace, where morale and loyalty are low, tension and stress are high, and legal pitfalls abound.
--Joe--
Well, she certainly looks like one in her picture, and an attractive one at that. (Even more attractive when you consider she's into computers and reads Slashdot.) And no, I'm not providing a link for all you HNG's. (Yes, I realize that could be a picture of someone else, but what would be the point of getting worked up on conspiracy theories?)
I guess you can tell what type I go for, when you consider that my fiancee meets many of the same 'attractiveness' critereon. :-)
Knock 'em dead, elfbabe!
--Joe--
Point taken. Thank you for the clarification on this part. I'm more familiar with their current business model than with their previous.
I'm not sure I buy the "Postscript-enabled Proprietary Applications" argument, though. What's to stop these app developers from providing support for some other common interface (say PPM) and saying to people, "Hey, you can get Postscript support really easy by doing this:..."
I'm not sure I follow. What happens when Mfgr X builds up some proprietary system which needs the reliability of ReiserFS, and ships it along with a Linux kernel source tarball containing ReiserFS? If the ReiserFS itself is an integral part of the product (say, for reliability reasons or whatever), then how is this any different from the Ghostscript case you mention? If Namesys is counting on charging all commercial customers, then this doesn't work. I doubt they are, though.
One possible application I can think of that falls in this category is a Point-of-Sale system. I can imagine the folks implementing these systems needing reliability as well as the recovery aspects that ReiserFS provides. At the same time, the POS software itself is highly proprietary, and is using the filesystem as a client. Say WhizBang POS Systems starts shipping their proprietary, binary-only POS software on a CD with the Linux kernel and ReiserFS patches installed. For GPL compliance, they have a big source tarball containing Linux+ReiserFS. How is this different from the Ghostscript scenario you described?
The availability of GPL exceptions is more likely to affect people with closed OSes, or OSes whose license is not GPL compatible. (eg. QNX, the BSDs, other embeddeded and commercial OSes.) For instance, suppose I want to integrate ReiserFS into a DSP design running SPOX. I would need to license ReiserFS for that application. I suspect that is the crowd that these license exceptions are aimed at -- it's not the same story as for Ghostscript.
Or did I miss something?
(PS. I'm not trying to be antagonistic or anything. I find this to be an interesting and enlightening discussion, and I'm truly trying to understand the subtleties.)
--Joe--
Actually, I hear that he's not thrilled with it. Indeed, one of the biggest problems that I can see is that there is very little incentive for people to improve the existing GPL version of Ghostscript when they know that Aladdin has (a) already improved Ghostscript in the current commercial version, and (b) will be releasing their changes 'soon' (after one year). This interview with Ghostscript's author Peter Deutsch sheds more light on the situation, including Stallman's thoughts.
One result is that the GPL community is almost guaranteed to always be one year behind the latest in Ghostscript technology, unless someone gets up enough nerve to fork Ghostscript development and try to get ahead of Aladdin.
Part of the problem here is that the Aladdin folks try to license their code to printer manufacturers, etc. The printer folks aren't too keen on having to ship Ghostscript on demand to anyone who buys a printer. Also, if the printer folks make any platform specific changes (which undoubtedly they will, such as specific driver technology for running the print engine), they'd have to distribute those changes, and most aren't willing to do so.
Also, more importantly, Peter Deutsch doesn't seem too keen on having people ship Postscript-enabled printers by using his work for free (as in gratis).
The upshot: Aladdin offers their latest and greatest Ghostscript with a commercial license.
With ReiserFS, I'm sure a similar but not identical set of considerations exist. People building embedded or mission critical systems on an otherwise proprietary base might license ReiserFS for their application without introducing any questions as to the effects of GPL. At the same time, a GPL version is available for everyone.
The difference here is a bit subtle but important. Namesys appears to be releasing the latest and greatest ReiserFS under GPL, rather than imposing an artificial delay. (Whether or not this changes in the future is unclear, but for now it is an important distinction.) In this case, the commercial license seems to be a means for companies to buy an "unencumbered" version of ReiserFS for their own purposes. (By "unencumbered", I mean free of the implications of GPL.) I see this potentially as a way to keep both camps happy. Maybe. (Except, of course, RMS.)
--Joe--
Isn't it somewhat interesting that no more than a year ago, Linux had no journalling filesystems. Then everyone complained. Now we're going to have three journalling filesystems! (XFS, ReiserFS, and ext3) If anyone cares to complain about the lack of responsiveness of the free software community, I suggest you take a look at this. ;-)
I guess good things come in threes?
Heh, I just happened to think, there's a few other places the "good things come in threes" applies:
Anyone else have some favorite 'threes' to add?
--Joe--
You could boot from an initrd RAM Disk, load the XFS module, and then remount your root partition from an XFS partition on your hard-drive. After all, this is how RedHat kernels allow you to have your root partition on a SCSI drive, yet still have all of the SCSI devices built as modules.
Indeed, just this sort of technique can also be used to handle a ReiserFS root partition that needs to be fsck'd, by having the boot routines in the RAM disk image do the fsck if necessary. Strikes me as a bit more fragile than what I'd care to deploy in a mission critical setting, but....
--Joe--
Linux may not be an official Unix, but it is good for Unix. That alone makes it an important event in Unix history.
It's important in the same way IBM PC clones were important to IBM. They weren't IBM PCs, but the fact that they were compatible and completely changed IBM's impact on the world was fairly relevant. Linux seems to be having a similar effect with respect to Unix.
--Joe--
The lp1 on fire bit wasn't in the docs, was it?
BTW, who remembers the rest of the tunefs joke? (Namely, the bits that were in the actual nroff source for the man page?)
From what I recall, the man page's source said something along the lines of "Remove this, and a Unix daemon will dog your steps until the time_t's wrap around." I unfortunately do not have access to a system with the original quote that I know of offhand. Anyone?
--Joe--
As the AC above noted, C's default assuptions about pointer aliasing make certain classes of programs run like crap. The new restrict keyword is a huge step in the right direction, but it's still a Band-Aid.
Why are sane pointer aliasing conventions important in the language? Well, since effecient code generation is something nearly everyone lusts after, compiler writers spend alot of effort "optimizing" code. Since C doesn't provide much of a mechanism for describing where pointers point, the compiler has to implement alot of guesswork. If it's not sure, it punts and outputs slow code.
The problem is that these optimizations are hard to get right. Notice how GCC 2.95 broke the Linux kernel, unless you compiled with the new alias analysis turned off. It would be better for the language to have saner pointer semantics.
Note that this wasn't so much of a problem in the beginning when pipelines were short and issue-widths were narrow. Nowadays, though, pointer aliasing issues are one of the biggest issues preventing code from going faster. (I know, I hit these issues regularly.) I welcome restrict with open arms.
--Joe--
I stand corrected. The main point is still valid: Copper is faster because RC went down. Instead of R being less, it sounds like it was C. Thanks for the info! :-)
--Joe--
It's not just ASCII that's the issue. The problem is that humans tend to manipulate dates as 2-digit quantities. Y2K bugs happen all over the place regardless of what the internal representation is.
For instance, one case that shows up on POSIX systems is misuse of tm_year in struct tm. A common Y2K mistake: printf("Year: 19%02d\n", tm->tm_year);
One place I found a Y2K bug similar to this was in the Intellivision's EXEC ROM. The cartridge header stores the copyright year in a 10-bit field. (The year is given in years after 1900, so 1978 would be stored as the number 78). 10 bits is enough to go all the way to 2923, but the display code which displays the copyright hardcodes the '19' in front of the date and prints garbage for the third digit. The sad irony is that the EXEC does include routines for printing the whole 4-digit date properly. Nothing ASCII-specific about that.
On BCD (Binary-Coded Decimal) systems, storing a two-digit date in a byte was common. BCD-based systems are popular in banks and other financial settings due to the fact that BCD provides exact rounding for a decimal numeric representation. Again, non-ASCII. These bugs hit more of the ancient COBOL code than anything, though.
Other places Y2K problems show up are in forms and other places where humans are expected to enter dates. If the forms are designed to accept two characters for the year, then the software must assign some policy for picking the century. Different software has different policies, leading to all sorts of problems.
BTW, as long as I'm being nit-picky, the statement "pi == 3" is very accurate. It's just not terribly precise.
--Joe--
Bear in mind DPCE was based on Thinking Machines' C* language. The Thinking Machines boxes could have up to 65536 CPUs, and so it's reasonable to expect C* could generate code to make use of that. What's nice is that the programmer still writes in nice, linear code. The explicit loops they had to write before to do, say, a matrix multiplication, now become simple math operations. The compiler can then parallelize as it sees fit. The programmer actually sees nice linear code which is actually simpler than the looping code which he would've written before.
The people who want major parallelism (and can actually benefit from it) are numeric processing goons running weather simulations and other large number processing that is the traditional province of supercomputers. The other space where it is useful is in signal processing and graphics. The desktop crowd isn't going to care much, unless the parallelism gives them an extra frame per second in Quake III. :-)
As for knowing multiple paradigms: Yes, it's useful, just like learning foreign languages is beneficial, even if it only serves to help you understand your native tongue better. The problem is that not all programming paradigms are immediately useful to the task at hand, so many of us just don't have the time or inclination to get around to it. (I fall into this category.)
--Joe--
Awhile back, the X3J11 group responsible for the ANSI C standard was looking at some rather nifty data-parallel C extensions that retained the otherwise "serial programming" nature of the control code. I suspect that an evolutionary approach such as this is likely to gain more ground than forcing people to think about programming in a completely different paradigm.
Postscript and text files containing the Data Parallel C Extensions draft is available here: ftp://ftp.dmk.com/DMK/sc22wg14/data-parallel/
--Joe--
Not exactly, but close. Signal propogation delay is getting worse and worse with respect to clock cycle. In the early days, you could consider wire to have zero delay, since transistors were so slow compared to the propogation rate on the wire. As wires have gotten smaller and smaller, their resistance has gone up. Meanwhile we've packed them closer and closer together, so we have tons of capacitance between wires. And finally, transistors have gotten orders of magnitudes faster.
End result: It takes bloody ages for a signal to get anywhere on the chip with respect to how long it took to generate the signal.
Most pieces of silicon nowadays operate with various "domains", each of which has its own local clocking. Depending on how fast you're running, it can take several clocks just for a signal to travel from one end of the chip to the other, so designers tend to subdivide problems into domains that aren't more than a clock-cycle wide. Pipelines and replicated hardware help a little, but physics really starts to bite you in the arse. Copper helps a little here (since it lowers resistance), but it's not a cure-all either.
Our friendly constant 'c' is a couple orders of magnitude above the propogation rate on the chip, so it's not the main limiter. To put it into perspective, light travels 30cm every nanosecond, and chip dimensions are usually closer to 1cm on a side. But we're getting uncomfortably close. :-)
--Joe--
No, they're not.
So? Generating 32-bit constants is not what interesting programs spend most of their time doing. Optimize the common case.
To sum it up, I'd have to disagree on several points:
- Complex instruction decoders are a bottleneck to issuing large numbers of parallel instructions. It's more than just a power issue.
- The 32-bit constant generation example you have is not a typical bottleneck in most code. Control flow is more likely to be.
- x86 is less efficient than alot of other machines due to being a register-starved architecture. It has to rely on tricks such as store-to-load forwarding and micro-caches to turn a small cache of memory addresses into a pseudo-register file.
- While Intel has generally been the "Floating Point King" in x86 world (with Athlon recently taking the title away), x86 floating point as always sucked compared to architectures that have traditionally taken FP seriously. RISC wins squarely here, period.
--Joe--
*sigh* Not only do we have the usual cliches about patenting everything in sight (Stop breathing: You're infringing on patents 5,678,910 and 5,789,012), but also we have the (nowadays untrue) reiteration that the Y2K bug happened because programmers wanted to save a byte or two. When does this nonesense stop?
The Y2K bug happened because people window dates already. It of course seems absurd to patent the cause as the cure. The reason computers process dates with two-digit years is that humans process dates as two digit years. Twenty to thirty years ago, those two digits might have meant something in terms of storage, and yes, there is legacy COBOL code that is that old which exhibits the bug for that reason. Nowadays, those bytes are nothing, and the Y2K bug in modern software is mainly due to sloppy human custom being poorly translated to computer form.
Using two-digit years is a long-standing human practice, and let's face it, it's pretty arbitrary how we handle them. Humans generally have a pretty good sense of context, and I doubt machines will ever match it. Nonetheless, even humans can (and do) get tripped up.
*sigh*
--Joe--
Most of the ghosts look more like JPEG artifacts (eg. ringing and smoothing) than actual ghosts. To make this a serious endeavor, they need to take the IR filter off the camera and set the JPEG quality factor to maximum.
The rest look like they were done in Photoshop. One of them has such sharp lines on the "blurry ghost area" that it seems to be a rather obvious fake. (If the blurry area were that sharply delineated in real life, then there would've been more artifacts in the JPEG.)
Given the nature of it all, this looks more like a PR stunt than anything else. Welcome to the Web 1999!
--Joe --Joe--
The whole "fair"/"unfair" bit doesn't work well for me, either. I'd rather M2 work more like this:
For example, suppose this comment got moderated up once as Insightful and at about the same time got moderated up as Informative, and later got moderated down as Overrated. Depending on your frame of mind, all three moderations could be reasonable. (Particularly if the two +1 moderations came in about the same time such that the moderators didn't see each others' moderation. There's an inherent race condition in moderation.)
Now suppose the M2 page for three different users show one of the three moderations. In each case, it will show the state of the comment at the time it was moderated. (Perhaps, in light of the race condition mentioned above, it might be better to show the state of the comment as the original Moderator saw it, since two people could moderate the same comment without seeing each others' moderations ahead of time. It's not their fault that they don't automatically reload everytime someone else moderates.)
User 1 might see the first moderation's starting state: "Score: 1". User 1 gets to pick how they would've moderated the comment, given that starting score. Assuming they pick a moderation that's at least somewhat aligned with the Insightful moderation that was actually applied, then the moderator's karma goes up. If User 1 picks a moderation which may be in the same +1 direction, but is semantically completely different (eg. Funny), then the effect is neutral. If User 1 picks a moderation which is semantically similar but in the opposite direction (say, "Troll"), then the effect is negative on the original moderator's Karma.
User 2 gets a similar scenario, only they're presented with the post showing an original score of 2. (Or, if the race condition I mentioned above existed at the time of moderation, it too would show "Score: 1".) Their input is compared against the second moderation that was performed, namely, the Informative moderation. The same process applies.
In any case, User 3 would get to see the "Score: 3" initial state, and their response would be compared to the Overrated moderation.
The end result is that the semantic issue is abstracted away. Rob and company can decide how sematically similar Informative is to Insightful when they build the correlation lookup table. I'm guessing all "positive" moderations are at least loosely tied together (maybe a factor of 0.25, if you treat identical moderations as 1.0 correlation -- slightly more for the generic "Underrated" vs. the rest). Same story for the negatives.
At any rate, I don't think it ever really makes sense to call a particular act of moderation "fair" or "unfair", particularly if the comment was being marked with a postive moderation. Perhaps "appropriate" or "inappropriate" work better than "fair" or "unfair."
--JoePS. I'm going to CC: this to CmdrTaco as well.
--
A mailing list is only part of it, and often not a very big part of it. In the case of the New York Times, they don't seem to use your email address for much, if anything.
Rather, they're interested in demographic information, including whether or not you're willing to provide valid information on the form. Knowing their typical audience (eg. income bracket, etc.) as well as their willingness to provide such information gives them some powerful tools for better targeting their site (both articles and advertisements) at the readership.
If you use the same user-id each time, they also can build up statistics on readership patterns. This is likely why they have the "Save this ID on my machine" checkbox, in order to encourage this sort of consistent tracking.
Building a spam list which alienates readers is probably pretty low on their priority list right now.
--Joe--
For the people who accidentally click [Submit] twice and so on, could we have a "Suppress Post" button that users could use on their own posts? It'd put move the post to a score of -1 (or maybe even -2) immediately and would allow people a chance to clean up embarassing mistakes without completely sweeping them under the rug.
To prevent abuse, you might want to tie a -1 karma to the feature. Otherwise people might just stop using [Preview] altogether, or might start posting "guerrilla posts" -- posting something inflammatory, and then suppressing it before the moderators hit them. The -1 karma is much smaller than the 2 or 3 "Redundant" moderations, but is a large enough disincentive to prevent abuse, I think.
At any rate, it'll provide a way for posters to clean up after themselves.
Thoughts?
--Joe--
Actually, it already does that when I hit reply (except that the parent message is quoted above rather than below. Minor detail -- either way works.) How is yours configured?
As long as we're talking about the Reply page, is there any way we can get wider text boxes? I hate typing in these little tiny portals on the screen. Maybe make it configurable on the user page, so that the crowd using 1600x1200 with a flyspec-3 font can coexist with the crowd using 640x480 and a courier-24 font?
Also, could you escape out & symbols, replacing them with & when constructing the default text in the comment box for "Preview Mode"? That'll make all of the &symb; style symbols work properly when clicking Preview. (Right now, I kluge around it by hitting Back after a Preview so I don't have to hunt for all the &symb; symbols embedded in my comment.)
--Joe--
I think you mean improve rather than increase . A gamer's modem should have low latency, because high round trip times are bad for interactive response.
You are right though in your basic premise: There are various tricks the modem folks can pull to speed up modems. Probably the most effective trick would be to recognize IP/PPP/SLIP packet boundaries and use those as the quanta for compressing/error correcting, rather than the current "dumb wait" that modems currently do. (This was mentioned in an article linked elsewhere in comments.) Another would be to disable compression entirely for games, since it doesn't help much anyway -- the packets are too small.
As for analog vs. digital latency: The POTS network (POTS == Plain Old Telephone Service) is mostly digital anyway. The analog line you have in your home is usually converted to digital fairly quickly. The D/A in your modem coupled with the A/D in the POTS network do add some latency, typically equal to a couple sampling periods. At 8000 Hz, that would amount to around 1ms, if you assume a total of 8 sampling periods worth of conversion time and buffering.
--Joe--