Many open source packages are already in the mainstream: the Apache web server, Mac OS X (the kernel and BSD layer, at least), QuickTime streaming server, RealMedia server and client, Netscape Navigator and Communicator, and the BIND domain name resolution system, just to name a few, are all open source packages in common use by people all over the world. You can't get much more mainstream than that.
Motorola makes a couple of PowerPCbasedmicrocontrollers. These come with a number of usefull peripherals (USB endpoints, ethernet interfaces, serial ports, parallel I/O ports, etc.), some RAM and some EPROM all on a single chip. In decades past, Steve Ciarcia built a small publishing empire on the practice of building homebrew personal computers on similar microcontrollers (Z80 variants, in his case). The same approach could be used today. If you don't want to use a PowerPC, there are similar beasts available based on otherpopulararchitectures.
With one exception, none of the "standards" you mention are either very old or very standard. The exception is, of course, RS-232, which was defined in 1969 by the Electronic Industries Association of Washington D.C. (my home town). All of the others are relative infants:
The PC parallel port was defined, in a very loose manner, by IBM when the IBM-PC was introduced in the early 1980s. The original PC parallel port was unidirectional and good for little else than driving a printer. While a number of manufacturers offered bi-directional versions of the PC parallel port (including IBM, in the late 1980s, with the IBM-PS/2) no actual standard existed until the release of IEEE-1284, in the mid-1990s, which gives us the modern ECP/EPP option.
The VGA pin-out dates from the introduction of the IBM-PS/2 in 1988/1989.
The PC keyboard pin-out and protocol have only been around since the introduction of the IBM-PC, and have undergone at least two revisions, first for the IBM-AT keyboard, and second for the IBM-PS/2.
The reference to IDE having been around for 20 years is a pretty dubious one, unless you count IDE as just a variation on the vernerable IBM-PC expansion bus. (commonly known as the ISA bus) Still, 20 years ago, there was no such thing as IDE, even as a glimmer of a hope in anyone's eye.
on whether or not you like your current layout. When I moved from my apartment to my house, I used the opportunity to completely rearrange my living spaces. In the apartment I had gotten used to the arrangement of things and there was little opportunity or impetus for change. The house was a much bigger space, with many options that the apartment couldn't offer. I was able to both get rid of a bunch of junk that I didn't really need, as well as reorganize the stuff that remained into more usable living spaces.
In my case, the "throw like items into the same box" was a good strategy. If, however, you are very attached to your current arrangement, and you are moving to a space that is similar to the one you are leaving, you are probably better off going with a "room-by-room" boxing method.
My best advice, however, has to do with timing rather than packing: If you can do it, it is best to spread the moving process out over a few weeks. This is often not possible, since most people can't afford to pay rent on two places at once, but it makes the moving process much less hectic.
Aren't the current crop of Nintendo game consoles powered by a 64-bit MIPS?
No, they are powered by a 32-bit PowerPC-family chip.
Hm, nice try, but here we can see that the N64 uses a MIPS R4300i, which is a 64-bit device. I think your convusing N64 with the Sony Playstation.
Most variables have a minimum of 8 significant bits. The average length of a character string is in the 8-12 byte range (64-96 bits!)
..which almost always need to be operated on one character, i.e. 8 bits, at a time.
The components of a variable are not, themselves, variables. The rebuttal stands: most variables have far more than 8 significant bits.
All modern processors have 64-bit wide data busses
..and said transfers are used to fill cache lines, not to read individual variables. With 64-bit variables, you fit half as many into each of those cache lines, and thus go crashing back to memory accesses twice as often.
Still, once the data is in cache, the expense of getting at the data is essentially moot (there is plenty of bandwidth between cache and CPU core). The business of 64-bit variables taking up twice as much cache is a red herring since most variables (other than pointers) aren't dependant on the underlying architecture for their size.
The difference is that we have had plenty of 64 bit processors aimed at the lower end and they just don't work. It is too expensive to bring in 64 bits from RAM to cache when the average variable has less than 8 significant bits. Hence the packed words of VLIW Itanium.
Back when my job description included developing code for the Alpha and the Pentium, just paging in the larger 64 bit code killed the speed advantage of the Alpha chip.
What a load of bullshit!
First, what's this crap about 64-bit processors not working? There are plenty of MIPS, Alpha, Sparc and PowerPC based 64-bit systems that work just fine. Aren't the current crop of Nintendo game consoles powered by a 64-bit MIPS? How much more low-end do you need to go?
Second, what's this crap about most variables having less than 8 significant bits? Most variables have a minimum of 8 significant bits. The average length of a character string is in the 8-12 byte range (64-96 bits!) and integers and pointers are all (at least) 32-bits wide in modern systems (Windows, MacOS, and all unices).
Third, what's this crap about it being "too expensive" to transfer 64-bits of data in from RAM? All modern processors have 64-bit wide data busses and transfer data in 4-beat blocks (meaning 4*64-bits, or 256-bits at a time). This is true for the Pentium as well, at least since the Pentium II!
Finally, what's this crap about "paging in 64 bit code"? Just because Alpha (or Sparc, MIPS, or PowerPC) have 64-bit wide data registers doesn't make the code any bigger! Both the 32-bit and 64-bit variants of Sparc, MIPS, PowerPC and PA-RISC use the same size instruction words (32-bits), so there is no difference in code size.
Whatever your job description might have said, you clearly don't know what you are talking about.
the article is pure, sesational, bullshit. While life is a bit harder for the tweakers who were counting on the Appearance Manager API (which got 'Steved', along with lots of othe crap from the darkest days of Apple), there is still lots of themeing and tweaking going on: at least as much as there was in the early days of classic MacOS (back around 1984-1986). Things will get more interesting as the Cocoa APIs mature and folks get more familiar with them.
For the moment, however, there are a few malcontents that had a lot invested in the old way of doing things (the Kaliedescope folks) and just want to raise a stink because their sacred cow has been gored. The fact that Wired is giving them an audience simply underscores their journalistic calibre.
Anyone who really wants to customize the appearance of their OS X windows and controls can still do so. In fact, it is far easier in OS X than it was in classic Mac OS: In OS X, many of the window and control theme elements are stored as simple PDFs or TIFFs, somewhere in the/System hierarchy. All it takes to modify the appearance of things is to replace those PDFs or TIFFs, and, possibly, edit a.plist or two. Compare this to classic, where you had to write a bunch of code to insert your custom PICTs, MDEFs, CDEFs, and WDEFs into the system at runtime, and it's hard to see what anyone is griping about.
While not the lowest cost solution in the world, any relatively modern PowerMac fits the bill in terms of software ease-of-use, application support (when running OS X), and low power consumption.
The early model G3's shouldn't have any problem with the kind of network loads required (the cable/DSL bandwidth is going to top out before the CPU, disk or memory bandwidth becomes a problem) and should only cost about $400. Add in some extra RAM and a copy of OS X, and you're looking at no more than $650. If you go with Darwin, NetBSD, or one of the PowerPCLinux distro's, and you can get by with just the base system price.
If you really want a deal, and feel up to a bit of hardware hacking, you could look for a dead iMac. So long as the logic board is Ok, you should be able to hack together a power supply (if/when you need a monitor you can use any VGA style monitor with a Mac/VGA converter). The only real issue with an iMac would be support for a second hard-drive, but you might be able to make due with an external drive on a USB or Firewire port.
I don't know what a dead iMac goes for these days, but I can't believe you'd have to spend more than $300.
Now that they've fixed the lack of transactions (twice. What was wrong with the first time?) they can implement subselects and relational integrity. When they have all three implemented, I'll think about replacing PostgreSQL.
(P.S. Does MySQL have any support for checkpointing and hot backup, or do I have to take the whole database down during maintainance?)
A good overall Physics introduction for the non-technical reader is Physics for Poets by Robert March. It does an excellent job of covering the essentials of modern physics (from Gallileo to Heisenberg) without subjecting the reader to either too much mathematics (as with most good textbooks) or too many cartoons (as with most somepopularscience books).
If I were to receive an unsolicited item bearing a restrictive license of this sort, I would immediately send an invoice and rental agreement to the licensor for weekly storage and handling of their merchandise at my location, payable within 15 days unless the licensor came to my location and retrieved the item forthwith. Failure to retrieve the item within 15 days would indicate acceptance of the rental agreement.
Every month I would send a new invoice for the elapsed period, less payments, plus any late payment fees and interest.
When the total amount owed exceeded the local small-claims limit, I would confiscate the licensors' property for auction and file suit to recover the debt.
Yeah, yeah, and "We sent our daughter to a pretty yough girls school." So you've shown that you can construct pathological cases of English sentences that demand more than one sentence of context in order to be fully understood. My point, however, stands: The word "POLISH" does not depend for it's meaning on the capitalization of the first letter (or any other letter, for that matter), otherwise, you couldn't use it, meaningfully, as the first word of a sentence. Capitalization, in English, bears very little relation to word meaning.
That said, however, the conceit that capitalization is either vital or useless for word meaning is an entirely parochial prejudice. Rules that work well in English may be entirely wrong for another language. If we are going to talk, usefully, about how to manager the sorting and comparisson of file names, we need to consider more than just English usage.
<BILE> 'IT' may be a bit undervalued at the moment, that is to be expected after a long period of overvaluation, but not by much. In general, IT departments are dominated by badly trained monkeys who either couldn't make it in real technical fields, or wanted to make lots of money without doing any real work. (actually, there is a third category: the megalomaniacs looking for a way to lord thier power over the poor unfortunates who have to work with them) It is awfully hard to undervalue such folk.
The simple fact of the matter is that companies, even today, spend far too much money and effort on supporting their information systems. Some of this is due to the promulgation of inappropriate solutions (read: M$ bloatware). Some is due to the rank incompetance of the run-of-the-mill 'IT' worker (read: MC*E-bearing monkey). Obviously, a large part can be laid at the feet of CTOs and CIOs who don't put proper effort into either hiring or purchasing decisions.
So, the party's over and the bean counters are no longer willing to squander lots of money on faster machines to run more bloated software just to tickle some geek-wannabe's thirst for chrome. Boo-flippin-hoo! Good for the bean-counters! Putting 800MHz PIIIs on a secretary's desk just to type memos and emails was ridiculous in the first place. Now, anyone who recomended such silliness should be thankfull they haven't been tossed out on their ear.
As for how this will affect 'techies': don't make me laugh! 'IT' folk are not, in general, 'techies', they are administrative personnel. The real techies are off doing technical work and are in little or no danger from the 'IT' downturn. In fact, if the 'IT' downturn gets rid of the more obnoxious admins, all the better for the techs who don't have to deal with their crap. </BILE>
Nonesense, capitalization has nothing to do with it, only context is important. Consider the following sentence:
Polish you shoes or there will be hell to pay.
I'm sure you understood that perfectly well. It's all about context, not the case of the letters involved. Similarly, you can perfectly easily undertand the following:
POLISH OFF YOUR POLISH SAUSAGE BEFORE YOU GET SECONDS.
Again, caplitalization is meaningless, the context tells you which word is intended.
All that said, capitalization or other letter-forms can carry more information in other languages than in English. Diacritics can completely change the meaning of a character (English speakers don't have this, but it is important in most other European langauges and vital in some asian languages).
The question, really, is language specific, and is a real pain in the butt if you want to properly sort and compare strings for international usage. A related issue has to do with ligatures and glyph transformation in some middle-eastern languages: the same word can be spelled differently depending on it's position in a sentence or relative to other words.
There is, unfortunately, no simple solution to these problems.
Re:RISC != fewer instructions (despite acronym)
on
PowerPC Goes 64 bit
·
· Score: 2
daveman_1 wrote
And RISC will never make it onto the PC desktop.
What, precisely, do you mean by "never"?
There have been personal computer systems in use for at least 10 years that are based on RISC processors, not to mention a large number of game platforms and hand-held computers. In the desktop world, the fifth largest personal computer manufacturer has been selling only RISC based systems for the past 7 years.
I don't think that word means what you think it means.
RISC != fewer instructions (despite acronym)
on
PowerPC Goes 64 bit
·
· Score: 2
How many times do we need to go through this crap? Despite the reputed meaning of the acronym, RISC doesn't have anything to do with the number of instructions!
gelfling wrote
Clearly this is no longer a RISC design because the original PPC instruction set had what, 174 instructions? So add 160 more and you have 334.
and, earlier, autopr0n wrote
Yet Mac zealots will still be going on and on about how PPC is better because "Its RISC!". Never mind that the 486 only had 142 instructions total or anything like that.
RISC is about reduced complexity and designing architectures for best use by optimizing compilers.
If anyone actually wants to learn something (rather than simply spouting ignorant marketing propaganda) you can check out John Mashey's periodic RISC vs. CISC article from the comp.arch newsgroup.
The essence of the RISC philosophy can be summed up in this quote from Hennessey & Patterson: "Make the common case fast and rare case correct." The question is, however, how do we know what is the common case? The answer from H&P is to look at the occurrance of various instructions in actual programs. Since most programs are generated by compilers, this amounts to looking at what is used most commonly by compiler code generation engines.
Once you have made an inventory of instruction usage, what you find is that lots of time and instructions are spent moving data between registers and memory because you don't have enough registers, and over 80% of the addressing is done with only a couple of addressing modes. In other words, compilers are simply no good at making use of most complicated instructions common in most pre-RISC architectures (including the 80x86).
When you design an architecture that caters to the kind of usage a compiler likes, you come up with an architecture that has lots of registers and performs all arithmetic operations on values in the registers, only accessing memory with simple load and store instructions supporting a few simple addressing modes (absolute address, register direct, and, possibly, register direct with immediate index). Along the way, in order to make various CPU bookkeepping tasks as simple as possible, you will use a fixed length instruction word with only a few instruction formats, and ensure than any single instruction can only cause one fault condition (memory access fault, instruction operand fault, etc.)
This general description is a pretty good match for almost all, so-called, RISC architectures: MIPS, M88000, ROMP, POWER, PowerPC, PA-RISC, Alpha, AMD29000, Sparc, ARM, Clipper, etc. The fact that all of these architectures share so many common features says something profound about the descriptive power of the term 'RISC' which cannot, easily, be said of the converse term, 'CISC'.
Just to head off the other popular mis-conception concerning RISC vs. CISC: RISC has nothing to do with the implementation features of a given processor, only with the programmer visible architectural features (number of registers, instructions, instruction encoding, etc.). Hence, no matter what name Intel or AMD use to describe the current dynamic micro-coding scheme used to salvage another generation of bloated, power guzzling, 8-bit microcontroller follow-ons, the 80x86 will never be considered a RISC processor.
I work for one of the two main ETC (Electronic Toll Collection) companies and there is a reason that the state and local agencies don't try to track speed using the toll records: they wound never be able to make the speeding tickets stick. There are basically three problems with trying to issue speeding tickets based on toll transponder data:
The date and time on the toll transactions are not very exact. We try to keep all the computers in the lanes synchronized, but we don't do that great a job of it. If speeding tickets were issued to clients based on the computed travel time between entry and exit, the clients could simply claim that the entry and exit times weren't correct (and they'd be right).
The toll tag doesn't tell us anything about who was driving the car, or, for that matter, what car was being driven (unless there is a violation in the toll lane itself, in which case we take a picture of the back bumper, so we can identify the vehicle and license plate. We still can't tell who was driving).
With the red light cameras, the ticket is assessed against the vehicle (like a parking ticket) rather than against the driver's license (as with most speeding tickets) and the red light cameras get some proof that the ticketed vehicle was involved. With a calculated speeding ticket, however, there is no such proof. Again, the accused could simply say that neither they, nor their car, was on the road at that time, and there'd be no way to disprove it.
Finally, local agencies really don't want to piss of their clients. The reason for using the toll tags is to both increase collected toll revenue (there are lots of ways to lose toll revenue when cash is involved) and to better control traffic. If you penalize people for using the toll tags, you lose the ability to do the stuff you really want to do.
There is one other technical issue with trying to issue speeding tickets based on ETC data: most ETC systems don't collect enough data to make the calculation.
There are, basically, two types of toll facilities: boundry systems, where you get charged a toll each time you cross a boundry, and closed-loop systems, where you get charged based on the length of travel in the toll system. You can only calculate speed in a closed loop system, when both your entry and exit are recorded. Many toll systems are only boundry systems.
Even on a closed loop system, you can only calculate the average speed in the system. Under heavy traffic conditions, the average speed is likely never to exceed the posted speed limit! (this is the sad truth about speeding: it rarely benefits the speed but, occasionally, it is a great harm to an innocent bystander) You can pretty easily wipe out the extra time you gained by speeding while waiting to at the exit toll plaza.
Note, some agencies do issue fines for speeding thorugh the toll lanes, but that is a safety issue. None of the agencies that we work with issue actual speeding tickets based on speed in the toll lane. Also, many of the agencies maintain a constant police presence at the toll plazas, in order to go after violators. This was true even before there were ETC systems.
The ETC tags are pretty good for collecting information on what happens at the toll plazas. We can even get a fair amount of agregate information about the entire toll facility itself, based on plaza activity. But it is very difficult to extract information about individuals based on ETC data. The agencies seem to have a pretty good understanding of what the ETC data is good for and what legal limitations they are under.
One example to illustrate this point: Some of the original ETC installations took pictures of violators from in front of the vehicle, including a picture of the driver and passenger in the front seat. Now, however, we only take pictures of the front and rear bumpers, specifically avoiding either front or rear windshield.
The reason is a legal one. Early on in the history of ETC systems a law suit was brought against one of the local agencies because a driver had violated the toll lane and had his picture taken. The violation notice was mailed to his house, where it was opened by his wife. His wife was quite upset to find a picture of her husband and a strange woman driving in his car in the middle of the day!
The local agencies are now prevented, legally, from invading a driver's privacy by photographing the driver or passengers of a vehicle passing thorugh an ETC system. (We still get some interesting pictures, but only when the driver's have gone out of their way to make themselves visible to the lane cameras)
I don't see any good reason that OSI, which accepts a wide range of licenses, should reject a license because it requires active assent by the licensee. I would actually like to see EULAs that require more positive action than simply clicking a button: say, for instance, in order to accept the license you need to send something to the licensor, either by email or the regular paper post.
I'm a bit bemused by the idea that clicking a button during an installation process can bind me in the same way as a physical signature can. At least with physical signatures on physical documents (or even the electronic kind used at many retail stores these days) both parties to the transaction have some record that can be used, later, to prove who agreed to what. With a click-through license, there is only the presumption of acceptance, based on some pretty dodgy inductive reasoning (since you are using the software you must have, at some point in the past, clicked the "Ok" button on the license screen, hence you have agreed to, and are bound by, the EULA!).
Now, I can see that, for OSI approved license, where the original license holder may be difficult or impossible to contact, such a licensing policy would be very inconvenient, but for the bulk of commercial licenses, a more positive assent to the EULA would be preferable.
I'm sure there are things which spreadsheets can't handle well. Off the type of my head I can think of derivatives, integration, and solving simultaneous equations.
Huh? None of the things you mentioned are handled badly by a spreadsheet, at least not in the numerical sense. Integration is simply a sum of cell data. Derivation is obtained by taking the difference of adjacent cells. While solution of linear systems is a bit trickier, many spreadsheet packages either come with solver engines or have scripting langauges in which a simple solver can be written.
The one thing that I have found lacking in most spreadsheets is an easy way to fit curves to data sets. This is pretty glaring omission, given that you have both the data sets and a graphing tool in most spreadsheets. But then, I suppose that curve fitting is an alien concept to most of the financial world (though, I would think, statisticians might have some use for it).
A quick browse, however, through the Gnumeric Manual indicates that it has a linear solver and a host of statistical tools, which should allow you build almost any other numerical analysis tool you want.
Now, if you want to get symbolic results from a spreadsheet, you are probably screwed. But there are other tools that are better suited to such tasks than spreadsheets.
A common misconception. Studies have shown repeatedly that the human eye is generally able to read quicker and comprehend more when the text is presented in narrow columns of about 65 to 75 characters each, or about as wide as you can actually read at once with no eye motion.
65-75 characters is a bit wide to read with no eye motion. Most of the studies that have looked at this recommendsomething more like 40-50 characters, or about 7 words. This is width you commonly see in newspapers, magazines and other periodicals. Books, however, can be set on a wider body because we expect that books are read more slowly and deliberately than periodicals.
Optimum column width may also be affected by the 7-plus-or-minus-2 rule. Narrow columns mean that there are just enough words on a single line to be easily held in short term memory, thus easily 'digested' during reading.
Setting text on a computer display, however, is a different matter, especially when the display is configurable by the user. The assumption with the web is that the user will reconfigure both display size and text size to suite their circumstances. The fact that this guy thinks he knows better than his reads how they can best read text on screen, does not bode well for his qualifications as a user interface expert. (the first rule of user interface design is to listen to your users. This guy would rather dictate: it's no suprise that he worked for M$)
One could argue that any real work that happens on a PC - whether you're an executive secretary, a CEO or a developer - happens when you're typing stuff on the keyboard. The mouse is just a tool to launch stuff.
Possibly one could argue such a thing, if one had an exceptionally narrow view of what kind of work is done on PCs.
I can honestly say that, for the first six years that I worked with computers, the majority of my work was done with the mouse, not at the keyboard. I was a typesetter and layout artist for a small print shop, and only a small part of my work involved entering text at the keyboard. Most of what I did involved building grid layouts on screen and positioning bits of text and graphics on those grids. You couldn't ask for a more mouse intensive job. However, such tasks are not all that rare: CAD operators, GIS folk, graphic artists, and GUI designers all require the use of a pointing device for more than just launching applications.
The fact that Windows tries to use the mouse for everything, even tasks better suited to keyboard input, and many X Windows programs use the mouse for almost nothing, says more about the deficiencies of the GUI 'designers' working on Windows and X 11, than it does about the inate usefullness of mice versus keyboards.
What the hell does a crappy football team residing in the nation's capitol need maps for?
So they can find their way into and out of the city? (have you ever tried to navigate through Washington D.C.? Well, it's not like disting crops boy. Without precise directions you'll go the wrong way through an under-over or find yourself on Rt. 66 crossing the river into Virginia, and that'd end your trip real quick, wouldn't it.)
First, what do I do when someone submits a patch that violates my 'mission'? Should I try to be democratic about it and try to add it? Should I ignore it? What should I say to the contributor?
Ignore it. If you are not feeling particularly rude, you might respond to the submittor explaining why you are not going to use the submission. It's your project, you are the boss.
What if I get a patch that I don't understand? Perhaps it is garbage. Perhaps it is over my head and too complex for me to see how I can integrate it and still see the structure of my whole project.
Ignore it. If you are not feeling particularly rude, you might respond with a request for further explanation. It's you project, you are the boss.
What if someone gets angry and decides to fork the project? Under GPL, they would have the right to do this, but the excess competition could be unbeneficial when it would have been better for the contributor to wait for me to be ready for their suggestions at a later time.
Ignore it. If they want to strike out on their own, that's their prerogative. This concept you have of competition being 'unbenficial' is an odd one. The primary strength of the open source world is that we can allocate almost unlimited resources to every conceivable project and let the marketplace decide which are good and which are bad.
If someone else thinks that they can write a better widget than you can, they are free to try. Either way, we are all better off: more widgets, more choices, more for everyone.
I have had other (non-software) experiences, however, where people took my ideas and terribly misrepresented them and twisted them into utter confusion. People tried to 'contribute' but ended up just making a mess of things. Sometimes, it's very hard to maintain the integrity of something that you have worked very hard to build.
I don't consider myself a great visionary, so don't take words like 'vision' and 'mission' to be arrogant. I, like many others, simply have certain things I would like to express before I am ready to take certain suggestions. By 'finishing', I feel I am letting the world know what my ideas are and setting up a framework that others may find to be beneficial. Once a certain point is reached, I can let go, and people should feel free to do what they want. My goals, as an open source developer, are simply to share ideas. If those ideas, once fully expressed, are rejected or vastly mutated, so be it.
Yes, working with other people can be difficult and frustrating. If you want to maintain complete creative control and prevent others from modifying your work, the GPL may not be for you. If you want to make use of other people's time and tallent, then you have to give up some control or people will call you an overbearing ass. If, however, you reall care more about sharing ideas and getting things done, than about controlling every jot and tiddle of the project, then you can get a great deal out of open source colaboration.
So, lighten up. Set your project free as early as possible. Accept help from folk that share your vision, ignore the rest. Try not to be too rude. Don't get hung up over control or competition. Write good code and have some fun doing it.
Slashdot Mirror
Or, maybe he's actually an alien himself: Voron, Vogon,
My GOD! You mean it's not just a game?!? Those aliens are damn sneaky.
Facts, schmacts: the real benefit of assuming the unknown or unprovable is that you don't need to be bothered with any actual thought!
I thought that was Fox News: Fair and Unbiased (so much so, they need a logo proclaiming it)
Many open source packages are already in the mainstream: the Apache web server, Mac OS X (the kernel and BSD layer, at least), QuickTime streaming server, RealMedia server and client, Netscape Navigator and Communicator, and the BIND domain name resolution system, just to name a few, are all open source packages in common use by people all over the world. You can't get much more mainstream than that.
Motorola makes a couple of PowerPC based microcontrollers. These come with a number of usefull peripherals (USB endpoints, ethernet interfaces, serial ports, parallel I/O ports, etc.), some RAM and some EPROM all on a single chip. In decades past, Steve Ciarcia built a small publishing empire on the practice of building homebrew personal computers on similar microcontrollers (Z80 variants, in his case). The same approach could be used today. If you don't want to use a PowerPC, there are similar beasts available based on other popular architectures.
- The PC parallel port was defined, in a very loose manner, by IBM when the IBM-PC was introduced in the early 1980s. The original PC parallel port was unidirectional and good for little else than driving a printer. While a number of manufacturers offered bi-directional versions of the PC parallel port (including IBM, in the late 1980s, with the IBM-PS/2) no actual standard existed until the release of IEEE-1284, in the mid-1990s, which gives us the modern ECP/EPP option.
- The VGA pin-out dates from the introduction of the IBM-PS/2 in 1988/1989.
- The PC keyboard pin-out and protocol have only been around since the introduction of the IBM-PC, and have undergone at least two revisions, first for the IBM-AT keyboard, and second for the IBM-PS/2.
The reference to IDE having been around for 20 years is a pretty dubious one, unless you count IDE as just a variation on the vernerable IBM-PC expansion bus. (commonly known as the ISA bus) Still, 20 years ago, there was no such thing as IDE, even as a glimmer of a hope in anyone's eye.In my case, the "throw like items into the same box" was a good strategy. If, however, you are very attached to your current arrangement, and you are moving to a space that is similar to the one you are leaving, you are probably better off going with a "room-by-room" boxing method.
My best advice, however, has to do with timing rather than packing: If you can do it, it is best to spread the moving process out over a few weeks. This is often not possible, since most people can't afford to pay rent on two places at once, but it makes the moving process much less hectic.
Hm, nice try, but here we can see that the N64 uses a MIPS R4300i, which is a 64-bit device. I think your convusing N64 with the Sony Playstation.
The components of a variable are not, themselves, variables. The rebuttal stands: most variables have far more than 8 significant bits.
Still, once the data is in cache, the expense of getting at the data is essentially moot (there is plenty of bandwidth between cache and CPU core). The business of 64-bit variables taking up twice as much cache is a red herring since most variables (other than pointers) aren't dependant on the underlying architecture for their size.
What a load of bullshit!
First, what's this crap about 64-bit processors not working? There are plenty of MIPS, Alpha, Sparc and PowerPC based 64-bit systems that work just fine. Aren't the current crop of Nintendo game consoles powered by a 64-bit MIPS? How much more low-end do you need to go?
Second, what's this crap about most variables having less than 8 significant bits? Most variables have a minimum of 8 significant bits. The average length of a character string is in the 8-12 byte range (64-96 bits!) and integers and pointers are all (at least) 32-bits wide in modern systems (Windows, MacOS, and all unices).
Third, what's this crap about it being "too expensive" to transfer 64-bits of data in from RAM? All modern processors have 64-bit wide data busses and transfer data in 4-beat blocks (meaning 4*64-bits, or 256-bits at a time). This is true for the Pentium as well, at least since the Pentium II!
Finally, what's this crap about "paging in 64 bit code"? Just because Alpha (or Sparc, MIPS, or PowerPC) have 64-bit wide data registers doesn't make the code any bigger! Both the 32-bit and 64-bit variants of Sparc, MIPS, PowerPC and PA-RISC use the same size instruction words (32-bits), so there is no difference in code size.
Whatever your job description might have said, you clearly don't know what you are talking about.
Yes. Next question?
For the moment, however, there are a few malcontents that had a lot invested in the old way of doing things (the Kaliedescope folks) and just want to raise a stink because their sacred cow has been gored. The fact that Wired is giving them an audience simply underscores their journalistic calibre.
Anyone who really wants to customize the appearance of their OS X windows and controls can still do so. In fact, it is far easier in OS X than it was in classic Mac OS: In OS X, many of the window and control theme elements are stored as simple PDFs or TIFFs, somewhere in the /System hierarchy. All it takes to modify the appearance of things is to replace those PDFs or TIFFs, and, possibly, edit a .plist or two. Compare this to classic, where you had to write a bunch of code to insert your custom PICTs, MDEFs, CDEFs, and WDEFs into the system at runtime, and it's hard to see what anyone is griping about.
The early model G3's shouldn't have any problem with the kind of network loads required (the cable/DSL bandwidth is going to top out before the CPU, disk or memory bandwidth becomes a problem) and should only cost about $400. Add in some extra RAM and a copy of OS X, and you're looking at no more than $650. If you go with Darwin, NetBSD, or one of the PowerPC Linux distro's, and you can get by with just the base system price.
If you really want a deal, and feel up to a bit of hardware hacking, you could look for a dead iMac. So long as the logic board is Ok, you should be able to hack together a power supply (if/when you need a monitor you can use any VGA style monitor with a Mac/VGA converter). The only real issue with an iMac would be support for a second hard-drive, but you might be able to make due with an external drive on a USB or Firewire port.
I don't know what a dead iMac goes for these days, but I can't believe you'd have to spend more than $300.
(P.S. Does MySQL have any support for checkpointing and hot backup, or do I have to take the whole database down during maintainance?)
A good overall Physics introduction for the non-technical reader is Physics for Poets by Robert March. It does an excellent job of covering the essentials of modern physics (from Gallileo to Heisenberg) without subjecting the reader to either too much mathematics (as with most good textbooks) or too many cartoons (as with most some popular science books).
Every month I would send a new invoice for the elapsed period, less payments, plus any late payment fees and interest.
When the total amount owed exceeded the local small-claims limit, I would confiscate the licensors' property for auction and file suit to recover the debt.
That said, however, the conceit that capitalization is either vital or useless for word meaning is an entirely parochial prejudice. Rules that work well in English may be entirely wrong for another language. If we are going to talk, usefully, about how to manager the sorting and comparisson of file names, we need to consider more than just English usage.
'IT' may be a bit undervalued at the moment, that is to be expected after a long period of overvaluation, but not by much. In general, IT departments are dominated by badly trained monkeys who either couldn't make it in real technical fields, or wanted to make lots of money without doing any real work. (actually, there is a third category: the megalomaniacs looking for a way to lord thier power over the poor unfortunates who have to work with them) It is awfully hard to undervalue such folk.
The simple fact of the matter is that companies, even today, spend far too much money and effort on supporting their information systems. Some of this is due to the promulgation of inappropriate solutions (read: M$ bloatware). Some is due to the rank incompetance of the run-of-the-mill 'IT' worker (read: MC*E-bearing monkey). Obviously, a large part can be laid at the feet of CTOs and CIOs who don't put proper effort into either hiring or purchasing decisions.
So, the party's over and the bean counters are no longer willing to squander lots of money on faster machines to run more bloated software just to tickle some geek-wannabe's thirst for chrome. Boo-flippin-hoo! Good for the bean-counters! Putting 800MHz PIIIs on a secretary's desk just to type memos and emails was ridiculous in the first place. Now, anyone who recomended such silliness should be thankfull they haven't been tossed out on their ear.
As for how this will affect 'techies': don't make me laugh! 'IT' folk are not, in general, 'techies', they are administrative personnel. The real techies are off doing technical work and are in little or no danger from the 'IT' downturn. In fact, if the 'IT' downturn gets rid of the more obnoxious admins, all the better for the techs who don't have to deal with their crap.
</BILE>
All that said, capitalization or other letter-forms can carry more information in other languages than in English. Diacritics can completely change the meaning of a character (English speakers don't have this, but it is important in most other European langauges and vital in some asian languages).
The question, really, is language specific, and is a real pain in the butt if you want to properly sort and compare strings for international usage. A related issue has to do with ligatures and glyph transformation in some middle-eastern languages: the same word can be spelled differently depending on it's position in a sentence or relative to other words.
There is, unfortunately, no simple solution to these problems.
What, precisely, do you mean by "never"?
There have been personal computer systems in use for at least 10 years that are based on RISC processors, not to mention a large number of game platforms and hand-held computers. In the desktop world, the fifth largest personal computer manufacturer has been selling only RISC based systems for the past 7 years.
I don't think that word means what you think it means.
gelfling wrote
and, earlier, autopr0n wrote
RISC is about reduced complexity and designing architectures for best use by optimizing compilers.
If anyone actually wants to learn something (rather than simply spouting ignorant marketing propaganda) you can check out John Mashey's periodic RISC vs. CISC article from the comp.arch newsgroup.
The essence of the RISC philosophy can be summed up in this quote from Hennessey & Patterson: "Make the common case fast and rare case correct." The question is, however, how do we know what is the common case? The answer from H&P is to look at the occurrance of various instructions in actual programs. Since most programs are generated by compilers, this amounts to looking at what is used most commonly by compiler code generation engines.
Once you have made an inventory of instruction usage, what you find is that lots of time and instructions are spent moving data between registers and memory because you don't have enough registers, and over 80% of the addressing is done with only a couple of addressing modes. In other words, compilers are simply no good at making use of most complicated instructions common in most pre-RISC architectures (including the 80x86).
When you design an architecture that caters to the kind of usage a compiler likes, you come up with an architecture that has lots of registers and performs all arithmetic operations on values in the registers, only accessing memory with simple load and store instructions supporting a few simple addressing modes (absolute address, register direct, and, possibly, register direct with immediate index). Along the way, in order to make various CPU bookkeepping tasks as simple as possible, you will use a fixed length instruction word with only a few instruction formats, and ensure than any single instruction can only cause one fault condition (memory access fault, instruction operand fault, etc.)
This general description is a pretty good match for almost all, so-called, RISC architectures: MIPS, M88000, ROMP, POWER, PowerPC, PA-RISC, Alpha, AMD29000, Sparc, ARM, Clipper, etc. The fact that all of these architectures share so many common features says something profound about the descriptive power of the term 'RISC' which cannot, easily, be said of the converse term, 'CISC'.
Just to head off the other popular mis-conception concerning RISC vs. CISC: RISC has nothing to do with the implementation features of a given processor, only with the programmer visible architectural features (number of registers, instructions, instruction encoding, etc.). Hence, no matter what name Intel or AMD use to describe the current dynamic micro-coding scheme used to salvage another generation of bloated, power guzzling, 8-bit microcontroller follow-ons, the 80x86 will never be considered a RISC processor.
With the red light cameras, the ticket is assessed against the vehicle (like a parking ticket) rather than against the driver's license (as with most speeding tickets) and the red light cameras get some proof that the ticketed vehicle was involved. With a calculated speeding ticket, however, there is no such proof. Again, the accused could simply say that neither they, nor their car, was on the road at that time, and there'd be no way to disprove it.
There is one other technical issue with trying to issue speeding tickets based on ETC data: most ETC systems don't collect enough data to make the calculation.
There are, basically, two types of toll facilities: boundry systems, where you get charged a toll each time you cross a boundry, and closed-loop systems, where you get charged based on the length of travel in the toll system. You can only calculate speed in a closed loop system, when both your entry and exit are recorded. Many toll systems are only boundry systems.
Even on a closed loop system, you can only calculate the average speed in the system. Under heavy traffic conditions, the average speed is likely never to exceed the posted speed limit! (this is the sad truth about speeding: it rarely benefits the speed but, occasionally, it is a great harm to an innocent bystander) You can pretty easily wipe out the extra time you gained by speeding while waiting to at the exit toll plaza.
Note, some agencies do issue fines for speeding thorugh the toll lanes, but that is a safety issue. None of the agencies that we work with issue actual speeding tickets based on speed in the toll lane. Also, many of the agencies maintain a constant police presence at the toll plazas, in order to go after violators. This was true even before there were ETC systems.
The ETC tags are pretty good for collecting information on what happens at the toll plazas. We can even get a fair amount of agregate information about the entire toll facility itself, based on plaza activity. But it is very difficult to extract information about individuals based on ETC data. The agencies seem to have a pretty good understanding of what the ETC data is good for and what legal limitations they are under.
One example to illustrate this point: Some of the original ETC installations took pictures of violators from in front of the vehicle, including a picture of the driver and passenger in the front seat. Now, however, we only take pictures of the front and rear bumpers, specifically avoiding either front or rear windshield.
The reason is a legal one. Early on in the history of ETC systems a law suit was brought against one of the local agencies because a driver had violated the toll lane and had his picture taken. The violation notice was mailed to his house, where it was opened by his wife. His wife was quite upset to find a picture of her husband and a strange woman driving in his car in the middle of the day!
The local agencies are now prevented, legally, from invading a driver's privacy by photographing the driver or passengers of a vehicle passing thorugh an ETC system. (We still get some interesting pictures, but only when the driver's have gone out of their way to make themselves visible to the lane cameras)
I'm a bit bemused by the idea that clicking a button during an installation process can bind me in the same way as a physical signature can. At least with physical signatures on physical documents (or even the electronic kind used at many retail stores these days) both parties to the transaction have some record that can be used, later, to prove who agreed to what. With a click-through license, there is only the presumption of acceptance, based on some pretty dodgy inductive reasoning (since you are using the software you must have, at some point in the past, clicked the "Ok" button on the license screen, hence you have agreed to, and are bound by, the EULA!).
Now, I can see that, for OSI approved license, where the original license holder may be difficult or impossible to contact, such a licensing policy would be very inconvenient, but for the bulk of commercial licenses, a more positive assent to the EULA would be preferable.
The one thing that I have found lacking in most spreadsheets is an easy way to fit curves to data sets. This is pretty glaring omission, given that you have both the data sets and a graphing tool in most spreadsheets. But then, I suppose that curve fitting is an alien concept to most of the financial world (though, I would think, statisticians might have some use for it).
A quick browse, however, through the Gnumeric Manual indicates that it has a linear solver and a host of statistical tools, which should allow you build almost any other numerical analysis tool you want.
Now, if you want to get symbolic results from a spreadsheet, you are probably screwed. But there are other tools that are better suited to such tasks than spreadsheets.
Optimum column width may also be affected by the 7-plus-or-minus-2 rule. Narrow columns mean that there are just enough words on a single line to be easily held in short term memory, thus easily 'digested' during reading.
Setting text on a computer display, however, is a different matter, especially when the display is configurable by the user. The assumption with the web is that the user will reconfigure both display size and text size to suite their circumstances. The fact that this guy thinks he knows better than his reads how they can best read text on screen, does not bode well for his qualifications as a user interface expert. (the first rule of user interface design is to listen to your users. This guy would rather dictate: it's no suprise that he worked for M$)
Possibly one could argue such a thing, if one had an exceptionally narrow view of what kind of work is done on PCs.
I can honestly say that, for the first six years that I worked with computers, the majority of my work was done with the mouse, not at the keyboard. I was a typesetter and layout artist for a small print shop, and only a small part of my work involved entering text at the keyboard. Most of what I did involved building grid layouts on screen and positioning bits of text and graphics on those grids. You couldn't ask for a more mouse intensive job. However, such tasks are not all that rare: CAD operators, GIS folk, graphic artists, and GUI designers all require the use of a pointing device for more than just launching applications.
The fact that Windows tries to use the mouse for everything, even tasks better suited to keyboard input, and many X Windows programs use the mouse for almost nothing, says more about the deficiencies of the GUI 'designers' working on Windows and X 11, than it does about the inate usefullness of mice versus keyboards.
If someone else thinks that they can write a better widget than you can, they are free to try. Either way, we are all better off: more widgets, more choices, more for everyone.
Yes, working with other people can be difficult and frustrating. If you want to maintain complete creative control and prevent others from modifying your work, the GPL may not be for you. If you want to make use of other people's time and tallent, then you have to give up some control or people will call you an overbearing ass. If, however, you reall care more about sharing ideas and getting things done, than about controlling every jot and tiddle of the project, then you can get a great deal out of open source colaboration.So, lighten up. Set your project free as early as possible. Accept help from folk that share your vision, ignore the rest. Try not to be too rude. Don't get hung up over control or competition. Write good code and have some fun doing it.