Ultimately, embedding a graphical display into your function keys is useless.
If you're using function keys and you don't know what they mean, the last thing you want to do is look at the keyboard, which usually involves moving your head and refocusing on an object at a different distance than the object you've been staring at for some time. That's a major time-sink if your goal is improving the efficiency of user input, and it'll give the user a neck-ache from the repetitive motion. It's much better to provide function key hints on the screen, where the user can already see them, until such time as they can be memorized--then make them go away.
Conversely, if you know what the function keys mean, and you want more bandwidth for input to the machine, you aren't going to wait for the display on the function key to catch up and display the correct intended meanings. A good typist won't bother looking at the keys to figure out where "Q" is--they already know where "Q" is, so they just hit the key without looking, and have already hit the next key before the machine has had a chance to do all the data processing that pressing "Q" might trigger.
In this manner GPL code is far more dangerous to BSD codebases than proprietary code. Proprietary code simply borrows code, GPL code not only borrows code, but it oftentimes borrows Open Source developers as well. Much of the work that is being done by Linux developers can't be used by BSD developers unless they are willing to use the GPL style licenses as well.
Perhaps you could clarify the difference here? How is a proprietary developer not contributing to your code different from an open-source developer not contributing to your code? The legal theory is identical.
I can see that there would be something annoying about the experience of seeing your code, with someone else's improvements incorporated into it, publicly available for anyone to use, but licensed in such a way that you can't use it yourself without modifying the terms of your software license; however, except for secrecy, this is true of proprietary code too.
Re:You may need a for-loop
on
Date Pagers
·
· Score: 1
Trouble with that approach is that if you're waiting for her to send you a signal (so you can instantly send a matching signal) and she's waiting for you to send her a signal (so she can instantly send a matching signal)...well, nobody ever sends anything, so she goes off with the jock in the corner who doesn't know how to build a hacked device (or worse, _you_ go off with the jock in the corner...).
Obviously you wouldn't want to go off with her if she doesn't know how to build a hacked device herself.
You need to transmit something...so transmit several randomized signals (faking the source address, if any, of course, each time, in order to force different responses in case there's some kind of anti-tampering protocol), then determine if _she_ has a hacked unit that responds to each one.
Then you just walk over and say "Hi. Nice hacked pager job you have there. Can I buy you a drink?"
Naturally, this protocol totally collapses if more than two people are doing it within radio-shot of each other...and it gets even worse if you have one person between two people who are out of range of each other.
I always thought that if you were temporarily dead, the time gets deducted off of your allowance for when you're permanently dead. E.g. if your copyright is in effect 75 years (IIRC) after your death, then if you die for three days, live a while, then die again, you only get 74 years, 362 days (give or take).
Of course, in the case of this particular author, the copyright rules were amended several times during His lifetime (and didn't exist at all for much of it). Also due to His multi-jurisdictional nature, consistent application of the law is a bit...difficult.
Obviously this hasn't come up in case law yet because most people who are dead for more than a minute or two tend to stay dead, and nobody is going to launch a lengthy and expensive legal feud over a one-time two-or-three-minute delay when they could just go grab a coffee and the problem will go away by itself.;-)
Uhhh...1984 is at least six, possibly seven or eight years older than the very first 404 error, at least from a protocol running on port 80. You could make it work with FTP, I guess...
The problem with embedded flash rom's is that upgrading the software in them is not quite as trivial as upgrading software installed on top of Windows 95.
An upgrade _always_ entails a certain amount of risk. There's a very real risk that during an upgrade, the consumer's embedded device will be made totally unusable, either due to introduction of new bugs, botched procedure (e.g. errors or power failure during the critical data transfer), version mismatches ("Oh, you wanted the Nukea 6190-A-US-1999-05 version, you have the 6190-AA-US-1999-05 version. As a result, you've destroyed the flash loader and melted the microwave transmitter in the process...guess you need a new phone now, eh?"), and vendor abuse ("the CSS update for the all-in-one DVD-player-and-set-top-web-browser has been complete. In addition to being able to access web sites with cascading style sheets, we have also corrected that little problem where the DVD player component would play discs with foreign region codes. Your European movie collection is now entirely useless to you, but _wow_ look at our new web site!").
It's bad enough that vendors barely do any testing before they release a product and try to restrict what we can do with it afterwards. Why would we want to remove the incentive to act responsibly at all?
I read Slashdot in "lite" mode because the bottleneck for me is the page rendering in the browser, not the Internet connection. All praise Netscape.
Ultimately, the "everyone will eventually have more bandwidth" argument isn't very well thought out. Yes, if everything is uncongested and operating at 100% efficiency, all things being equal, people in the future will be able to load much larger web pages than they do now; however, this growth takes decades.
Part of the problem is that the throughput possible when moving the data in a web page across the net is not linearly related to the raw size of the pipe used to fetch it. Packets are getting smaller relative to the size of the data (or at least staying the same while the data grows), and the congestion penalty on the Internet--that is, the multi-second delays caused by TCP stalls--comes from losing a single packet. Congestion behavior is difficult (if not impossible) to predict, and it's prohibitively expensive to equip every router in the Internet with "enough" memory to make congestion a non-issue.
If your web page fits in three network packets, you're much less likely to lose one of the packets in transit than if the page needs thirty or three hundred. You can escape random packet loss more often if your pages are smaller.
Another problem is simple scalability. If your web page is 10 times smaller than the competition's, then you can serve 10 times as many users, if you and your competitor have feeds of the same size.
I have been faster than the system I use since approximately 1983. When is this much-fabled upgrade going to happen such that the machine finally catches up with me?
I was doing this in 1994 as part of a Usenet binary newsgroup unposting program. To save web server space, the program kept a table of checksums of every file (frequently caused by cross-posting) and replaced identical files with hard links to a single file. Should've patented the damn thing, just for the satisfaction of the privilege of sending a cease and desist order to Microsoft.
That would be the only use of a software patent that my conscience would allow...;-)
Oh well. Mac people were doing network backups based on a similar concept almost a decade ago, which predates my work. Can't remember the name of the package, though.
Hmmm...I guess after 10 years, Microsoft gets to copy other people's good ideas in their own products, so the Single Instance Store is right on schedule. Gosh, I feel old now.
just so happens to try to send to a host named "foo." first, then appends the system's notion of my local domain name. I guess that's why they force all host name registrations to contain two levels, otherwise there would be software chaos...
Encrypt the message text and the keys. Change keys often. Destroy old keys--preferably by non-recoverable methods such as dissolving a CD-R with the only non-RAM copy of your keys on it in a solution of fun petrochemicals before setting it on fire.
It's hard to securely delete megabytes of email a day, but if it's strongly encrypted and you securely delete a few hundred bytes of key, the mail is just as unreadable. There will, of course, be nothing to disclose. If they need proof you can show them your CD-R destruction equipment.
I've observed the behavior of quite a few SMP systems lately and I've noticed that theory and practice don't always agree. Simply trying to add MHz numbers together is wrong--it not only overestimates performance, it underestimates it as well. An SMP system is so different from a UP system that benchmarks are more or less meaningless without knowing the structure of the application.
You would think that a 1 GHz processor would run faster than two 500 MHz processors in real life. Certainly, for a narrowly defined set of applications (single-threaded CPU-intensive cache-bound operations) this is true. If you utilize all of your CPU's at full efficiency (in terms of total number of operations completed per second in one machine) then a single 1GHz part will produce more than twice as much throughput as two 500MHz parts in an SMP configuration, all other factors being equal. This is because the 1GHz part doesn't have to suffer bus contention or SMP signalling overhead while the pair of 500MHz parts do, so 1x1GHz CPU is theoretically faster than 2x500MHz CPU even if the speed difference is as small as one clock cycle per second.
However, real life does not always agree with the theory. It all comes down to efficiency: if you can't get 100% efficiency out of your CPU, you will typically get more total efficiency from two CPU's than you will from one. This increase in efficiency will actually make the two-CPU system more than twice as fast as the one-CPU system even at the _same_ clock rate. In other words, two CPU's are usually better than one CPU at twice the clock rate.
Why is this? Well, there's a two major factors, really: inefficient software and inefficient hardware.
The software people typically use (applications written using general-purpose libraries and development tools and operating systems designed to run general-purpose applications) sucks. It's an absolute efficiency nightmare. A lot of the performance features of an OS are workarounds for applications that don't (or can't) know better; e.g. virtual memory relieves an application designer of the obligation to manage RAM efficiently, but it does a very bad job unless the OS model of memory access happens to match the application's actual behavior. You can lose more than half of the processing capabilities of the machine to even the most efficient and powerful operating systems.
Running an OS with pipes, sockets, disk cache, virtual memory, processes, I/O buffers, graphics drivers, network stacks, protected address spaces, and other "conveniences" is really inefficient in terms of extra data copying, context switches, and other bus bandwidth around the CPU. A lot of these constructions are faster when implemented in an SMP system than in a single-processor system simply because one CPU can do the overhead while the other does useful (i.e. non-OS-overhead) work at the same time. It's like adding a hardware accelerator for OS overhead, and it has the same effect on OS performance that most video accelerators have on video performance. Of course, if you write a stand-alone program (i.e. you replace the entire OS) in hand-tuned assembly language designed to accomplish your one task, then it will run faster on the 1GHz 1-CPU system than the 500MHz 2-CPU SMP system--but very few people actually do that, so the advantage is non-existent for most users. Note that "None of the above" has always been and is still the industry leader in the embedded OS market, where every CPU cycle counts.
Enough about bad software, now let's talk about bad hardware. Yes, there is a tiny core of high-speed memory (128K or so, compared to hundreds of megabytes of slow RAM in a good size system) that is actually running at 1GHz. But that memory is attached to a L2 cache running at half that rate, and the L2 cache is attached to a memory bus running at 30% (at most) of the L2 cache clock rate. If your CPU hits the PCI bus, your CPU is stalled waiting for a clock cycle that is a whopping 30 times slower than the 1GHz CPU core. If your CPU hits the ISA bus...well, hopefully if you care about speed at all, you simply don't have ISA cards in your machine running between 125 and 1000 times slower (depending on transaction size and wait states) than your CPU core...
If you want a nice humorous read, read the Intel Pentium Optimization manual. The Pentium III is just an 8008 with lots of new features grafted on to it--features such as an asymmetric parallel executing RISC unit that you can only access through a braindead synchronous CISC instruction decoder. The PIII instruction set is heavily optimized for pointer arithmetic and ASCII character string operations, so it performs really well on benchmarks, but there are still a lot of instructions that cause the execution units of a PIII to stall for a few clock cycles at a time, and a few instructions that cause a stall lasting _dozens_ of clock cycles. This combined with cache locality (i.e. the CPU's aren't trying to use the shared memory bus 100% the time) means that memory access contention in an Intel SMP system is a non-issue for most people since the "other" CPU is very frequently stalled or busy and doesn't need the memory bus anyway.
When your CPU gets stalled doing these slow operations, it can often be running at 3% of its overall efficiency or less. Most of the "slow" operations only stall the CPU for a handful, if any, clock cycles, but even those can reduce efficiency to at most 20%. If you have a single CPU, at any speed, it is going to completely stall and your machine will sit idle for hundreds of picoseconds; however, if you have two CPU's, you can often make use of one while the other is stuck in one of these slow operations. A two-CPU system executing two threads with this kind of bus access pattern can give very close to twice as much throughput as a single-CPU system, all things being equal.
Of course, this assumes that both CPU's are equivalent in efficiency to a single CPU doing the same task, but this is often not the case--in fact, the efficiency of each individual CPU typically goes up because it has fewer context switches and less L2 cache traffic to deal with. These two operations are the big instruction pipeline stall generators. Remember: one cache miss is equivalent to about 100 integer operations.
Two CPU's means twice the L2 cache. Do not ignore this advantage. Main memory is slow--about 10 times slower than the core of a 1GHz CPU. You will never notice the difference in speed between a 500MHz and 1GHz CPU if you're spending all your time waiting for a 133MHz memory bus because you have insufficient L2 cache to do the job you want to do. 512K is good enough for desktop systems (128K or 256K is good enough for toys) but you need 1 meg or more cache in order to really notice how fast a 500MHz Intel CPU can go.
What that means in practice is that we are often comparing a machine running at one execution unit at 1GHz with 20% efficiency with a machine running two execution units at 500MHz with 30% and 90% efficiency. Do the math, and you find that the 500MHz 2-way SMP system is running at 300% of the throughput of the 1GHz UP system.
Yes, that's three times faster with the cheaper parts. Clock rates don't add at all.
Theory gets us again in the end, though. Single-threaded CPU-intensive cache-bound applications do come along from time to time, and on the 2-way 500MHz SMP system these applications will run at half the speed of the 1GHz UP system. Even worse, two truly memory-bound tasks executed in parallel on a 500MHz SMP system will take twice as long to run as the same two tasks executed sequentially on a 1GHz UP system (so instead of 1 result in 1 second you get nothing in 1 second and 2 results in 2 seconds). So it averages out in the end--some applications are much faster while others are much slower.
But the sad fact is, a well-tuned 2-CPU SMP system running a typical Linux desktop will be somewhere on the order of 3-5 times faster than a comparable 1-CPU UP system running at the same clock rate, particularly for an office-suite style of application usage. That means a real person doing office work on a 2-CPU 500MHz system is working not just as fast as a 1-CPU 1GHz system, but typically 1.5 to 2.5 times faster. And of course the CPU parts themselves are somewhat cheaper...
"echo 1 >/proc/sys/net/ipv4/icmp_echo_ignore_broadcasts" should be sufficient.
Anyway, if using ipchains, I prefer:
"ipchains -A input -i ! -d -j DENY"
where 'ifname' is each interface and 'ifaddr' is the corresponding address. That basically ignores all broadcast or multicast traffic; only point-to-point IP to _your_ host is accepted. Of course if you have a router or you actually need to receive broadcast traffic for some reason, you have to RTFM...
The vast majority of Slashdot-effect traffic is going to have Referrer fields pointing to the article in question. Simply grabbing any 10 requests and analyzing them will usually tell you where they're coming from...unless it's a DDoS attack, of course.;-)
Wine can be used to recompile Windows applications to run on Unix. They work as well as the windows application binary running under the WINE emulator, really.
Wine is not really an emulator, it's just a very very different implementation of/lib/ld-linux.so.2, libpthreads, libX11, etc.
This brings up an interesting side-issue...is scalability a feature that is considered in UI design? It doesn't seem to be, although I really do want it.
I have all the problems AC does with Windows and trying to run a lot of small applications. The entire OS from the internals all the way up to the UI is designed around running a handful of really bloated applications. It has problems coping with lots of small applications, or combining applications in useful ways (unless of course the applications involved are designed from the ground up to work with each other--and conceptually that's just really one application with two inseparable modules).
I've never been able to make Windows understand that I want all text and border decorations to be minimally sized because I want to put ~20 windows on the display at the same time. In Linux this isn't always trivial but it's at least possible.
Personally, I'd like to use a UI (as well as its associated "look and feel" rules, which are really conventions for application implementors) such that applications will run as well on my 1600x1200x24 X display(s), with dozens of open windows, as they do on a Palm Pilot's 160x160x1 stylus screen. Unfortunately, many modern applications have difficulty even resizing their windows that small, much less working afterwards.
Interestingly enough, the Palm Pilot Developer's Guide (http://www.palm.com/devzone/docs/pptdg/TableOfCon tents.htm suggests that Palm applications, _unlike desktop applications_, should be small and fast, should display useful information to the user right away, and be task-specific. This implies to me that somewhere there's an unwritten rule that desktop applications should be slow and bloated, should require the user to fight with the UI to get the information they want, and should include all sorts of features unrelated to the task they perform. Frankly, I prefer single clicks instead of double clicks (gosh, when was the last time I ever double-clicked for anything other than selecting words from text? 1996? Even Windows' right-click-drag-release for "open" is better than double-clicking...), I like applications that try to display maximum useful information in limited screen area (or, conversely, display maximum aesthetic appeal given unlimited screen area), and I like applications that are task-oriented and don't try to do everything that other apps already do.
Of course the Palm's GUI design is a direct copy of the MacOS design in many places, and I am impressed with how well it has managed to capture almost all of the MacOS flaws. They could have built the system around Unix-like text files (with transparent compression for data transfer and long-term storage to conserve memory) instead of the broken MacOS creator/type filesystem--at least that way you'd have some hope of combining two small, memory-limited applications into one larger, more useful one. Thank God it doesn't have a Windows Registry...
Well, there was also the problem that SLS sucked much more than Slackware did. I managed to repair SLS to the point where it could be used to bootstrap a complete set of Linux sources. Then Slackware came along, and I managed to repair that to the point where it could be used to bootstrap a complete set of Linux sources. Then Red Hat came along, and for the first time there was a vendor that was fixing bugs faster than I could on my own in my spare time.
_That_ was cool, at least at the time (1996).
I was able to use Red Hat's precompiled kernels for the first time in late 1998. That was cool too.
Red Hat still requires a lot of post-installation fixes before it becomes useful, but they're getting smaller and smaller.
I'm planning to explore Debian sometime soon (I have to do this given where I work anyway) but it's not a big priority for me until I actually get a new machine to play with. Right now I don't feel like debugging an alien Linux distribution for which I don't have a workaround script ready to drop on it as soon as the installer finishes.
RPM runs on Solaris and I've heard noises from one of the *BSD's about it. That means that the RPM *packager* and *database engine* work. Unfortunately, the *data* contained *inside* the RPM (gee, look at all those asterisks;-) doesn't actually work when it gets there.
Consider ssh*.rpm install scripts--they'll write their startup scripts in/etc/rc.d/init.d/sshd and use/sbin/chkconfig to configure them, which is great as long as the rest of the distribution actually puts its startup scripts there and has a/sbin/chkconfig. If you try installing this RPM on Debian, you won't get very far.
Of course other distributions can respond to this by installing a tree of symbolic links and conversion scripts so that Red Hat's configuration data from 3rd-party RPMs can be used in the "native" distribution. Try proposing that to Debian and see what the response is like...
Microsoft's first (and probably last) legal line of defense would be to say "You did not exercise due diligence when you were operating that Windows NT computer without regular backups in case it ate your data."
The idea of a Microsoft lawyer having to state on public record that data-eating crashes are a normal part of day-to-day NT operation leaves me with this happy happy feeling...;-)
Sigh. Prepare for an onslaught of "Linux is only for people who can't afford Microsoft" FUD because of this. Thank you, Mike, you've just undone six months of hard work by Linux advocates in a single sentence.:-(
I don't generally perceive Windows license fees as a tax, mostly because I've never actually paid the Windows tax. My employers have purchased the copies of Windows that I have used at one time or another, but I haven't done so myself. I've never had Windows at home except on machines loaned to me by my employer, so I haven't avoided the "tax" through piracy either. It's only in the last three months that I've even considered the Windows license fees as a "tax" (which means that the consumer-awareness campaigns are working--keep it up, guys!:-)
I did buy a 386 in ~1992 that came with MS-DOS but at the time I only wanted a program loader for a Borland C compiler. My _real_ work was done on my OS-9 box at the time, so I consider that MS purchase an ordinary consumer purchase, not a tax payment. Six months later the same 386 was running SLS Linux 1.01. I have an image of that machine on a CD-R somewhere...
I do object to the shoddy quality of Microsoft software, which is why I refuse to pay for it, or even use it if it was paid for by someone else. I use Linux because it is materially better than Microsoft software, not because I don't want to give money to a particular corporation. I give my money to big corporations all the time. Big corporations pay my salary. I don't have a problem with this.
Besides, it actually costs _more_ to get the lowest of the low-end Linux-based systems because the dirt cheap hardware (WinModems et al) isn't supported by Linux.
So if you're just looking to avoid spending money, look elsewhere.
The GPL is incompatible with a number of patents held on MP3 encoding. There will be no GPLed MP3 encoders in countries that honor such patents until they expire.
Ummm...I hate to have to point this out, but the office suite code is significantly larger than that of the Linux distribution required to run it. It only makes sense to add a basic Debian system to the office suite, not the other way around.
SPI, Inc. (or whoever the makers of Debian are) does not operate a for-profit business that may be considered a competitor to Corel.
Corel's approach to several other free software groups is quite benign (so far). Some Corel employees join e.g. Wine as developers and contribute code according to the same rules as everyone else. They also go out of their way to implement the ugly but really useful stuff (OLE support for Wine, anyone?). There's no reason to expect Debian to be corrupted just because Corel wants to contribute to it.
2. Linux for people who want to be Unix users someday, and
3. Linux for other users.
Windows users _like_ to pay for every single feature in their systems--if they get too much at once, they demand the product be broken into cheaper pieces or pieces with less "learning curve."
Note how most corporate Windows machines are used: as office equipment, just like a cash register (sometimes _as_ a cash register), photocopier, etc. The machine has to do exactly one thing and do it over and over again. Even a home Windows user just loads one game after the next. People in corporate environments actually _demand_ _reduced_ functionality from Windows boxes (e.g. no possibility of even accidentally running a web browser) for kiosks/point-of-sale/photocopier-with-pentium-iii- processor applications.
It would be very _difficult_ to screw up Linux to the point where you can't remote-login to the box and do remote administration (although you might have to install your own sshd, but if you're doing remote admin then presumably you can do that anyway) without disabling the entire box. Corel (or anyone else) would have to go out of their way to break that, e.g. by changing the binary formats so the standard Linux dynamic loader doesn't work.
Slashdot Mirror
Ultimately, embedding a graphical display into your function keys is useless.
If you're using function keys and you don't know what they mean, the last thing you want to do is look at the keyboard, which usually involves moving your head and refocusing on an object at a different distance than the object you've been staring at for some time. That's a major time-sink if your goal is improving the efficiency of user input, and it'll give the user a neck-ache from the repetitive motion. It's much better to provide function key hints on the screen, where the user can already see them, until such time as they can be memorized--then make them go away.
Conversely, if you know what the function keys mean, and you want more bandwidth for input to the machine, you aren't going to wait for the display on the function key to catch up and display the correct intended meanings. A good typist won't bother looking at the keys to figure out where "Q" is--they already know where "Q" is, so they just hit the key without looking, and have already hit the next key before the machine has had a chance to do all the data processing that pressing "Q" might trigger.
I can see that there would be something annoying about the experience of seeing your code, with someone else's improvements incorporated into it, publicly available for anyone to use, but licensed in such a way that you can't use it yourself without modifying the terms of your software license; however, except for secrecy, this is true of proprietary code too.
Trouble with that approach is that if you're waiting for her to send you a signal (so you can instantly send a matching signal) and she's waiting for you to send her a signal (so she can instantly send a matching signal)...well, nobody ever sends anything, so she goes off with the jock in the corner who doesn't know how to build a hacked device (or worse, _you_ go off with the jock in the corner...).
Obviously you wouldn't want to go off with her if she doesn't know how to build a hacked device herself.
You need to transmit something...so transmit several randomized signals (faking the source address, if any, of course, each time, in order to force different responses in case there's some kind of anti-tampering protocol), then determine if _she_ has a hacked unit that responds to each one.
Then you just walk over and say "Hi. Nice hacked pager job you have there. Can I buy you a drink?"
Naturally, this protocol totally collapses if more than two people are doing it within radio-shot of each other...and it gets even worse if you have one person between two people who are out of range of each other.
I always thought that if you were temporarily dead, the time gets deducted off of your allowance for when you're permanently dead. E.g. if your copyright is in effect 75 years (IIRC) after your death, then if you die for three days, live a while, then die again, you only get 74 years, 362 days (give or take).
;-)
Of course, in the case of this particular author, the copyright rules were amended several times during His lifetime (and didn't exist at all for much of it). Also due to His multi-jurisdictional nature, consistent application of the law is a bit...difficult.
Obviously this hasn't come up in case law yet because most people who are dead for more than a minute or two tend to stay dead, and nobody is going to launch a lengthy and expensive legal feud over a one-time two-or-three-minute delay when they could just go grab a coffee and the problem will go away by itself.
Uhhh...1984 is at least six, possibly seven or eight years older than the very first 404 error, at least from a protocol running on port 80. You could make it work with FTP, I guess...
The problem with embedded flash rom's is that upgrading the software in them is not quite as trivial as upgrading software installed on top of Windows 95.
An upgrade _always_ entails a certain amount of risk. There's a very real risk that during an upgrade, the consumer's embedded device will be made totally unusable, either due to introduction of new bugs, botched procedure (e.g. errors or power failure during the critical data transfer), version mismatches ("Oh, you wanted the Nukea 6190-A-US-1999-05 version, you have the 6190-AA-US-1999-05 version. As a result, you've destroyed the flash loader and melted the microwave transmitter in the process...guess you need a new phone now, eh?"), and vendor abuse ("the CSS update for the all-in-one DVD-player-and-set-top-web-browser has been complete. In addition to being able to access web sites with cascading style sheets, we have also corrected that little problem where the DVD player component would play discs with foreign region codes. Your European movie collection is now entirely useless to you, but _wow_ look at our new web site!").
It's bad enough that vendors barely do any testing before they release a product and try to restrict what we can do with it afterwards. Why would we want to remove the incentive to act responsibly at all?
I read Slashdot in "lite" mode because the bottleneck for me is the page rendering in the browser, not the Internet connection. All praise Netscape.
Ultimately, the "everyone will eventually have more bandwidth" argument isn't very well thought out. Yes, if everything is uncongested and operating at 100% efficiency, all things being equal, people in the future will be able to load much larger web pages than they do now; however, this growth takes decades.
Part of the problem is that the throughput possible when moving the data in a web page across the net is not linearly related to the raw size of the pipe used to fetch it. Packets are getting smaller relative to the size of the data (or at least staying the same while the data grows), and the congestion penalty on the Internet--that is, the multi-second delays caused by TCP stalls--comes from losing a single packet. Congestion behavior is difficult (if not impossible) to predict, and it's prohibitively expensive to equip every router in the Internet with "enough" memory to make congestion a non-issue.
If your web page fits in three network packets, you're much less likely to lose one of the packets in transit than if the page needs thirty or three hundred. You can escape random packet loss more often if your pages are smaller.
Another problem is simple scalability. If your web page is 10 times smaller than the competition's, then you can serve 10 times as many users, if you and your competitor have feeds of the same size.
I have been faster than the system I use since approximately 1983. When is this much-fabled upgrade going to happen such that the machine finally catches up with me?
I was doing this in 1994 as part of a Usenet binary newsgroup unposting program. To save web server space, the program kept a table of checksums of every file (frequently caused by cross-posting) and replaced identical files with hard links to a single file. Should've patented the damn thing, just for the satisfaction of the privilege of sending a cease and desist order to Microsoft.
;-)
That would be the only use of a software patent that my conscience would allow...
Oh well. Mac people were doing network backups based on a similar concept almost a decade ago, which predates my work. Can't remember the name of the package, though.
Hmmm...I guess after 10 years, Microsoft gets to copy other people's good ideas in their own products, so the Single Instance Store is right on schedule. Gosh, I feel old now.
echo Surprise! | mail me@foo
just so happens to try to send to a host named "foo." first, then appends the system's notion of my local domain name. I guess that's why they force all host name registrations to contain two levels, otherwise there would be software chaos...
Encrypt the message text and the keys. Change keys often. Destroy old keys--preferably by non-recoverable methods such as dissolving a CD-R with the only non-RAM copy of your keys on it in a solution of fun petrochemicals before setting it on fire.
It's hard to securely delete megabytes of email a day, but if it's strongly encrypted and you securely delete a few hundred bytes of key, the mail is just as unreadable. There will, of course, be nothing to disclose. If they need proof you can show them your CD-R destruction equipment.
I've observed the behavior of quite a few SMP systems lately and I've noticed that theory and practice don't always agree. Simply trying to add MHz numbers together is wrong--it not only overestimates performance, it underestimates it as well. An SMP system is so different from a UP system that benchmarks are more or less meaningless without knowing the structure of the application.
You would think that a 1 GHz processor would run faster than two 500 MHz processors in real life. Certainly, for a narrowly defined set of applications (single-threaded CPU-intensive cache-bound operations) this is true. If you utilize all of your CPU's at full efficiency (in terms of total number of operations completed per second in one machine) then a single 1GHz part will produce more than twice as much throughput as two 500MHz parts in an SMP configuration, all other factors being equal. This is because the 1GHz part doesn't have to suffer bus contention or SMP signalling overhead while the pair of 500MHz parts do, so 1x1GHz CPU is theoretically faster than 2x500MHz CPU even if the speed difference is as small as one clock cycle per second.
However, real life does not always agree with the theory. It all comes down to efficiency: if you can't get 100% efficiency out of your CPU, you will typically get more total efficiency from two CPU's than you will from one. This increase in efficiency will actually make the two-CPU system more than twice as fast as the one-CPU system even at the _same_ clock rate. In other words, two CPU's are usually better than one CPU at twice the clock rate.
Why is this? Well, there's a two major factors, really: inefficient software and inefficient hardware.
The software people typically use (applications written using general-purpose libraries and development tools and operating systems designed to run general-purpose applications) sucks. It's an absolute efficiency nightmare. A lot of the performance features of an OS are workarounds for applications that don't (or can't) know better; e.g. virtual memory relieves an application designer of the obligation to manage RAM efficiently, but it does a very bad job unless the OS model of memory access happens to match the application's actual behavior. You can lose more than half of the processing capabilities of the machine to even the most efficient and powerful operating systems.
Running an OS with pipes, sockets, disk cache, virtual memory, processes, I/O buffers, graphics drivers, network stacks, protected address spaces, and other "conveniences" is really inefficient in terms of extra data copying, context switches, and other bus bandwidth around the CPU. A lot of these constructions are faster when implemented in an SMP system than in a single-processor system simply because one CPU can do the overhead while the other does useful (i.e. non-OS-overhead) work at the same time. It's like adding a hardware accelerator for OS overhead, and it has the same effect on OS performance that most video accelerators have on video performance. Of course, if you write a stand-alone program (i.e. you replace the entire OS) in hand-tuned assembly language designed to accomplish your one task, then it will run faster on the 1GHz 1-CPU system than the 500MHz 2-CPU SMP system--but very few people actually do that, so the advantage is non-existent for most users. Note that "None of the above" has always been and is still the industry leader in the embedded OS market, where every CPU cycle counts.
Enough about bad software, now let's talk about bad hardware. Yes, there is a tiny core of high-speed memory (128K or so, compared to hundreds of megabytes of slow RAM in a good size system) that is actually running at 1GHz. But that memory is attached to a L2 cache running at half that rate, and the L2 cache is attached to a memory bus running at 30% (at most) of the L2 cache clock rate. If your CPU hits the PCI bus, your CPU is stalled waiting for a clock cycle that is a whopping 30 times slower than the 1GHz CPU core. If your CPU hits the ISA bus...well, hopefully if you care about speed at all, you simply don't have ISA cards in your machine running between 125 and 1000 times slower (depending on transaction size and wait states) than your CPU core...
If you want a nice humorous read, read the Intel Pentium Optimization manual. The Pentium III is just an 8008 with lots of new features grafted on to it--features such as an asymmetric parallel executing RISC unit that you can only access through a braindead synchronous CISC instruction decoder. The PIII instruction set is heavily optimized for pointer arithmetic and ASCII character string operations, so it performs really well on benchmarks, but there are still a lot of instructions that cause the execution units of a PIII to stall for a few clock cycles at a time, and a few instructions that cause a stall lasting _dozens_ of clock cycles. This combined with cache locality (i.e. the CPU's aren't trying to use the shared memory bus 100% the time) means that memory access contention in an Intel SMP system is a non-issue for most people since the "other" CPU is very frequently stalled or busy and doesn't need the memory bus anyway.
When your CPU gets stalled doing these slow operations, it can often be running at 3% of its overall efficiency or less. Most of the "slow" operations only stall the CPU for a handful, if any, clock cycles, but even those can reduce efficiency to at most 20%. If you have a single CPU, at any speed, it is going to completely stall and your machine will sit idle for hundreds of picoseconds; however, if you have two CPU's, you can often make use of one while the other is stuck in one of these slow operations. A two-CPU system executing two threads with this kind of bus access pattern can give very close to twice as much throughput as a single-CPU system, all things being equal.
Of course, this assumes that both CPU's are equivalent in efficiency to a single CPU doing the same task, but this is often not the case--in fact, the efficiency of each individual CPU typically goes up because it has fewer context switches and less L2 cache traffic to deal with. These two operations are the big instruction pipeline stall generators. Remember: one cache miss is equivalent to about 100 integer operations.
Two CPU's means twice the L2 cache. Do not ignore this advantage. Main memory is slow--about 10 times slower than the core of a 1GHz CPU. You will never notice the difference in speed between a 500MHz and 1GHz CPU if you're spending all your time waiting for a 133MHz memory bus because you have insufficient L2 cache to do the job you want to do. 512K is good enough for desktop systems (128K or 256K is good enough for toys) but you need 1 meg or more cache in order to really notice how fast a 500MHz Intel CPU can go.
What that means in practice is that we are often comparing a machine running at one execution unit at 1GHz with 20% efficiency with a machine running two execution units at 500MHz with 30% and 90% efficiency. Do the math, and you find that the 500MHz 2-way SMP system is running at 300% of the throughput of the 1GHz UP system.
Yes, that's three times faster with the cheaper parts. Clock rates don't add at all.
Theory gets us again in the end, though. Single-threaded CPU-intensive cache-bound applications do come along from time to time, and on the 2-way 500MHz SMP system these applications will run at half the speed of the 1GHz UP system. Even worse, two truly memory-bound tasks executed in parallel on a 500MHz SMP system will take twice as long to run as the same two tasks executed sequentially on a 1GHz UP system (so instead of 1 result in 1 second you get nothing in 1 second and 2 results in 2 seconds). So it averages out in the end--some applications are much faster while others are much slower.
But the sad fact is, a well-tuned 2-CPU SMP system running a typical Linux desktop will be somewhere on the order of 3-5 times faster than a comparable 1-CPU UP system running at the same clock rate, particularly for an office-suite style of application usage. That means a real person doing office work on a 2-CPU 500MHz system is working not just as fast as a 1-CPU 1GHz system, but typically 1.5 to 2.5 times faster. And of course the CPU parts themselves are somewhat cheaper...
Hmmm...I sense a market here...
"echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts" should be sufficient.
Anyway, if using ipchains, I prefer:
"ipchains -A input -i ! -d -j DENY"
where 'ifname' is each interface and 'ifaddr' is the corresponding address. That basically ignores all broadcast or multicast traffic; only point-to-point IP to _your_ host is accepted. Of course if you have a router or you actually need to receive broadcast traffic for some reason, you have to RTFM...
The vast majority of Slashdot-effect traffic is going to have Referrer fields pointing to the article in question. Simply grabbing any 10 requests and analyzing them will usually tell you where they're coming from...unless it's a DDoS attack, of course. ;-)
Wine can be used to recompile Windows applications to run on Unix. They work as well as the windows application binary running under the WINE emulator, really.
/lib/ld-linux.so.2, libpthreads, libX11, etc.
Wine is not really an emulator, it's just a very very different implementation of
This brings up an interesting side-issue...is scalability a feature that is considered in UI design? It doesn't seem to be, although I really do want it.
n tents.htm suggests that Palm applications, _unlike desktop applications_, should be small and fast, should display useful information to the user right away, and be task-specific. This implies to me that somewhere there's an unwritten rule that desktop applications should be slow and bloated, should require the user to fight with the UI to get the information they want, and should include all sorts of features unrelated to the task they perform. Frankly, I prefer single clicks instead of double clicks (gosh, when was the last time I ever double-clicked for anything other than selecting words from text? 1996? Even Windows' right-click-drag-release for "open" is better than double-clicking...), I like applications that try to display maximum useful information in limited screen area (or, conversely, display maximum aesthetic appeal given unlimited screen area), and I like applications that are task-oriented and don't try to do everything that other apps already do.
I have all the problems AC does with Windows and trying to run a lot of small applications. The entire OS from the internals all the way up to the UI is designed around running a handful of really bloated applications. It has problems coping with lots of small applications, or combining applications in useful ways (unless of course the applications involved are designed from the ground up to work with each other--and conceptually that's just really one application with two inseparable modules).
I've never been able to make Windows understand that I want all text and border decorations to be minimally sized because I want to put ~20 windows on the display at the same time. In Linux this isn't always trivial but it's at least possible.
Personally, I'd like to use a UI (as well as its associated "look and feel" rules, which are really conventions for application implementors) such that applications will run as well on my 1600x1200x24 X display(s), with dozens of open windows, as they do on a Palm Pilot's 160x160x1 stylus screen. Unfortunately, many modern applications have difficulty even resizing their windows that small, much less working afterwards.
Interestingly enough, the Palm Pilot Developer's Guide (http://www.palm.com/devzone/docs/pptdg/TableOfCo
Of course the Palm's GUI design is a direct copy of the MacOS design in many places, and I am impressed with how well it has managed to capture almost all of the MacOS flaws. They could have built the system around Unix-like text files (with transparent compression for data transfer and long-term storage to conserve memory) instead of the broken MacOS creator/type filesystem--at least that way you'd have some hope of combining two small, memory-limited applications into one larger, more useful one. Thank God it doesn't have a Windows Registry...
Well, there was also the problem that SLS sucked much more than Slackware did. I managed to repair SLS to the point where it could be used to bootstrap a complete set of Linux sources. Then Slackware came along, and I managed to repair that to the point where it could be used to bootstrap a complete set of Linux sources. Then Red Hat came along, and for the first time there was a vendor that was fixing bugs faster than I could on my own in my spare time.
_That_ was cool, at least at the time (1996).
I was able to use Red Hat's precompiled kernels for the first time in late 1998. That was cool too.
Red Hat still requires a lot of post-installation fixes before it becomes useful, but they're getting smaller and smaller.
I'm planning to explore Debian sometime soon (I have to do this given where I work anyway) but it's not a big priority for me until I actually get a new machine to play with. Right now I don't feel like debugging an alien Linux distribution for which I don't have a workaround script ready to drop on it as soon as the installer finishes.
RPM runs on Solaris and I've heard noises from one of the *BSD's about it. That means that the RPM *packager* and *database engine* work. Unfortunately, the *data* contained *inside* the RPM (gee, look at all those asterisks ;-) doesn't actually work when it gets there.
/etc/rc.d/init.d/sshd and use /sbin/chkconfig to configure them, which is great as long as the rest of the distribution actually puts its startup scripts there and has a /sbin/chkconfig. If you try installing this RPM on Debian, you won't get very far.
Consider ssh*.rpm install scripts--they'll write their startup scripts in
Of course other distributions can respond to this by installing a tree of symbolic links and conversion scripts so that Red Hat's configuration data from 3rd-party RPMs can be used in the "native" distribution. Try proposing that to Debian and see what the response is like...
I'd love to actually see someone do this, though.
;-)
Microsoft's first (and probably last) legal line of defense would be to say "You did not exercise due diligence when you were operating that Windows NT computer without regular backups in case it ate your data."
The idea of a Microsoft lawyer having to state on public record that data-eating crashes are a normal part of day-to-day NT operation leaves me with this happy happy feeling...
Sigh. Prepare for an onslaught of "Linux is only for people who can't afford Microsoft" FUD because of this. Thank you, Mike, you've just undone six months of hard work by Linux advocates in a single sentence. :-(
:-)
I don't generally perceive Windows license fees as a tax, mostly because I've never actually paid the Windows tax. My employers have purchased the copies of Windows that I have used at one time or another, but I haven't done so myself. I've never had Windows at home except on machines loaned to me by my employer, so I haven't avoided the "tax" through piracy either. It's only in the last three months that I've even considered the Windows license fees as a "tax" (which means that the consumer-awareness campaigns are working--keep it up, guys!
I did buy a 386 in ~1992 that came with MS-DOS but at the time I only wanted a program loader for a Borland C compiler. My _real_ work was done on my OS-9 box at the time, so I consider that MS purchase an ordinary consumer purchase, not a tax payment. Six months later the same 386 was running SLS Linux 1.01. I have an image of that machine on a CD-R somewhere...
I do object to the shoddy quality of Microsoft software, which is why I refuse to pay for it, or even use it if it was paid for by someone else. I use Linux because it is materially better than Microsoft software, not because I don't want to give money to a particular corporation. I give my money to big corporations all the time. Big corporations pay my salary. I don't have a problem with this.
Besides, it actually costs _more_ to get the lowest of the low-end Linux-based systems because the dirt cheap hardware (WinModems et al) isn't supported by Linux.
So if you're just looking to avoid spending money, look elsewhere.
The GPL is incompatible with a number of patents held on MP3 encoding. There will be no GPLed MP3 encoders in countries that honor such patents until they expire.
If it's done right, Corel's distribution will be a subset of Debian with a different logo.
Think about it: why make your own distribution when you can just slap your own logo on top of Debian?
If Debian is not good enough, then contribute to Debian until it is good enough.
Ummm...I hate to have to point this out, but the office suite code is significantly larger than that of the Linux distribution required to run it. It only makes sense to add a basic Debian system to the office suite, not the other way around.
SPI, Inc. (or whoever the makers of Debian are) does not operate a for-profit business that may be considered a competitor to Corel.
Corel's approach to several other free software groups is quite benign (so far). Some Corel employees join e.g. Wine as developers and contribute code according to the same rules as everyone else. They also go out of their way to implement the ugly but really useful stuff (OLE support for Wine, anyone?). There's no reason to expect Debian to be corrupted just because Corel wants to contribute to it.
There are three kinds of Linux distribution:
- processor applications.
1. Linux for Unix users,
2. Linux for people who want to be Unix users someday, and
3. Linux for other users.
Windows users _like_ to pay for every single feature in their systems--if they get too much at once, they demand the product be broken into cheaper pieces or pieces with less "learning curve."
Note how most corporate Windows machines are used: as office equipment, just like a cash register (sometimes _as_ a cash register), photocopier, etc. The machine has to do exactly one thing and do it over and over again. Even a home Windows user just loads one game after the next. People in corporate environments actually _demand_ _reduced_ functionality from Windows boxes (e.g. no possibility of even accidentally running a web browser) for kiosks/point-of-sale/photocopier-with-pentium-iii
It would be very _difficult_ to screw up Linux to the point where you can't remote-login to the box and do remote administration (although you might have to install your own sshd, but if you're doing remote admin then presumably you can do that anyway) without disabling the entire box. Corel (or anyone else) would have to go out of their way to break that, e.g. by changing the binary formats so the standard Linux dynamic loader doesn't work.