One, I don't consider C++ to be a strongly typed language. Ada or Modula-2 yes, but not C/C++. The typing information is there, but it's easily bypassed, and often MUST be to do normal operations. >>>>>> Whoa there. Name *one* example where you *have* to do a typecast in properly written C++ code. Hell, just name one example where it is significantly cleaner/easier (to a C++, not C, programmer!) to do a cast rather then doing it the "right" way. Note, dynamic_cast, const_cast, and static_cast don't count, since they're type-checked, safe casts. Only reinterpret_cast here!
Um, an automatic conversion from 'int' to 'float' does not imply the language is not strongly typed. An 'int' and a 'float' represent the same concept (a number) and have similar representations at the machine level. As for the typedef, a typedef does not create a new type (if it did it'd be called 'typecreate'). It simply creates a shortened alias for a type. In the second statement, both 'Date' and 'int' are the same type, thus there is no conversion going on, thus the "strong-typed'ness" of the language isn't even being called into question.
PS> Introducing a new type with 'typedef' would be a major pain. Consider the case of template classes, which often are typedef'ed into a more readable representation:
Clearly, in a strongly typed language, foo should be able to take either an IntVector or a NumberVector, because they're the same type! Typedefs, in C++, are largely a convenience mechanism, and thus has semantics that lean towards convenience. Now, you could argue that there needs to be a 'typecreate' keyword that creates a new type out of an existing one, but that's another kettle of fish. The real question is, why not just use the existing type if it suits your purposes as is?
Correction. C does not have strong type checking. C++ has quite strong type checking, but provides a decent set of automatic conversions and provides an "out" for those that need it. reinterpret_cast(&foo) does not magically slip into your code. Not only is it pretty long to type, it's hard to spell "reinterpret." If it's there, you did it on purpose. And if you did it on purpose, the language should get the f**k out of your way and let you do it.
Actually, I studied OS design (and yes, I do read linux-kernel), which is the reason I am not as hostile to x86 as some people. You can say what you will about the elegance of the architecture, but in certain caes, it's just plain friendlier than others to the OS programmer. The VM model is relatively simple, it doesn't do weird stuff with memory-mapped I/O, it jumps through tons of hoops internally to keep interrupt semantics simple, etc. Once you wrap your head around segmentation (which is set it and forget it nowadays) it's pretty smooth sailing.
Um, what about this implies that you won't use the MMU? I'd prefer an object-level protection system like in the AS/400, but the MMU can easily be used to protect something like this.
It wouldn't matter. Only Apple can get the 1.8" drives at the moment, so everything else will be bigger. The iPod just slides under the "too big to pocket" limit. Even something just slightly larger (the Nomad Zen, for example) is too big.
The OGG bit might be a kicker, but if you can afford to re-rip, GET AN IPOD. The 20GB model is supposed to be priced-dropped to $400 this week. You'll appreciate the big (small) difference in size.
I've heard of all the problems in Africa, Kashmir, China, and the Philipines. However, those are really not as bad as the situation in the Middle East. The stuff about Israel is an oversimplification. If foreign policy were that simple, the US government wouldn't have so many problems with it. But I'll bite. Why do we support Israel so strongly? We weren't the only country involved in its creation. Could it be because it is powerful, US friendly democracy (kinda) in a region where we (thaks to oil) need influence and stability? Remember, nations have no friends, just interests.
x86 code is famously compact. According to the x86-64 docs, the average instruction length on x86 is about 3.2 bytes, significantly less than the 4 bytes of all 32-bit/64-bit RISC chips. Now ARM chips can have smaller code, but they do it through a 16-bit instruction set called ARM Thumb.
Memory mapping a harddrive won't make it faster to access, I agree. But simplifying parts of the code is a very big win. By memory mapping the HD, you can just let the page cache handle the I/O.
64-bit CPUs are really an OS designer's wet dream. There are lots of things (bounce buffers, dynamic RAM map, prelinking headaches) that just go away with a 64-bit address space. You can just map all RAM permenently, prelink all binaries to a unique address, and move on with your life (or lack thereof). I was thinking the other day, that with the move to database oriented filesystems like Reiser4 and LonghornFS (for lack of a better name) that the time is ripe for some of that OO research from the 80's and 90's to kick in. The gist is that instead of the basic abstraction being files with a strict naming hierarchy, the basic abstraction is a set of objects with a very flexible database index. Throw in object persistence, and you've got yourself a very elegant setup, with basically and OODBMS at the core of the system. However, straightforward (fast) implementations of the scheme blow away a 4GB address space. For something like this, you really want to be able to mmap() a 120GB harddrive and remove a whole lot of intervening hacks.
Actually, the modern PC architecture is just that, throughly modern.
1) The CPU: x86? Who cares? Even the Power4 does instruction-level translation, and advances like the trace cache take decode out of the hot path. In the end, x86 is just a nice, compact, widely supported bytecode. Outside of instructions, PC processors are very modern. Highly superscaler, highly pipelined, *very* high performance.
2) The chipset: This isn't your ISA system anymore. CPU -> chipset and chipset -> Memory interrconnects will be hitting 6.4 GB/sec by the end of the year. The Athlon 64 will have an integrated memory controller, just like the UltraSPARC. I/O hangs of the PCI bus, which is not a bottleneck given current systems. And when it does become a bottleneck, solutions like Hypertransport are already ready and working. Peripherals now hang off advanced busses like USB and Firewire, while traditional I/O methods are relegated to a tiny (cheap!) Super I/O chip. ISA is finally dead (the new Dells don't ship with ISA slots). The only thing we can't seem to get rid of is the infernal 8239 interrupt controller. The I/O APIC has been around for ages now. VIA has integrated them for years. Intel is finally getting around to putting them in, but is doing a half-assed job of it. My Inspiron has an 845 chipset, which theoretically has an IO-APIC, but it seems disabled for some reason.
3) The firmware: OSs today ignore the BIOS anyway. They're only in place for booting and SMM mode. ACPI has replaced most of what the BIOS used to be used for. Just this month, Intel said that EFI (used in the Itanium) will finally replace the PC BIOS, and bring with it a host of new features like support for high-resolution booting modes, network drivers, advanced debugging, etc.
Not only is sustainable energy good for the environment, but it's good for politics. The key question is: why do Middle Eastern terrorists, and many Middle Eastern non-terrorists, hate the West? The easy, overly simplistic, and thus popular, answer is because they're insane fundementalists who have a huge amount of pent up anger and will go after anything. This is no doubt partially true. Insane fundementalism is unfortunately a bane of human existance. However, the current level of animosity between two large segments of the world's population is too large to attribute soley to insanity. After all, the same level of conflict doesn't exist between the western countries and Asia, or them and Africa. A more encompassing answer is that terrorists have immense hatred because they're fundementalists, and the our continual meddling in the business of the Middle East just fuels their fire and gives them an excuse to take it out on us. Now, why do we continually meddle in the business of the Middle East? The answer is very clear. It's all about the oil. If it were not for oil, we would have absolutely no reason to be involved. It might very well be that without the stabilizing influence of western countries, the Middle East would degenerate into a mass of feuding, warring countries, but that was precisely the state of Europe for several centuries, and it would be supremely sanctimonious to believe that it would be in their best interest to be stabilized. It can be argued that such a state of existence is a natural phase in a region's progression, and that without such a phase, the real benifets of regional peace cannot be appreciated. Unfortunately, we cannot afford to base our decisions on philosophical ideals about the progression of civilizations. We need the oil, and we are pushed into a certain course of action in order to secure that oil. Rampant terrorism is the unfortunate consequence of a combination of impugned racial, regional, and national pride, and the latent hostility and fundementalism present in all human societies. Thus, Mr. Blair is more correct than it seems at first. Not only are sustainable energy sources less susceptible to terrorist attack, but moving to such sources greatly lessens the chances of such attack to begin with.
Re:Who needs a "Palm" device of ANY kind?
on
Palm PDA Roundup
·
· Score: 2, Interesting
a) a $.69 Mead notebook and a Bic or >>>>>>>> My dad has more contacts than most people have MP3s. He has something like a dozen scheduled phone calls and meetings a day. His situation is quite a common one. He replaced his overflowing 2-inch thick contact book with a 1/2-inch thick Sony Clie. He spends less time searching for names and numbers, and the thing gives a nice alert when he has an appointment. Of course, I spend a a lot of time troubleshooting the damn thing, but I figure he saves a good deal more time by using it than I waste fixing it:)
That's the point. You can't open up a PGP encrypted file unless you have PGP. You can't view secure web pages unless you have the crypto in your browser. You can't read Office DRM stuff unless you have Office. >>>>>> Interface vs implementation. PGP is an interface. SSL is an interface. There are many implementations of each. Office is itself an implementation. Tying a document to an interface is a technical necessity. Tying a document to an implementation is at best a stupid design decision, and at worst a market control tactic.
No one has to buy Office 2003. No one who does get Office 2003 has to use DRM. Anyone who does use the DRM is going to know that the readers of the data will need Office, and they'll be okay with that. If they weren't they wouldn't use it. >>>>>>> You give users far too much credit. People will buy Office 2003, if only because it's pretty much included with most computer sold at places like CompUSA. Second, if Office 2003 ships with DRM on by default (but with no access checks being performed), then they'll be using DRM whether they want to or not, because they don't know any better. It's the third point that's the kicker. Let me reiterate your statement:
Anyone who does use the DRM is going to know that the readers of the data will need Office >>>>>>>>>> That's not true right now. Right now, there exist numerous tools to open Office documents even if you don't have Office. Office DRM would prevent that, and give Microsoft more control of the document format. *That's* why this is a dangerous "feature."
Your complaint about it being Windows-only is bork. An Office DRM user is intending the reader of his/her document to be using Office. >>>>> Well, most users don't know that. They just use it without a second though. User's who use Office aren't clear that their being incompatible with the rest of the world. And a key thing is that they're really not. I can read an Office document in a pinch. Not in the age of Office DRM Edition.
It's the same way that the authors of Bash are intending the user of their app to be running Unix. >>>>> No. Bash runs on everything from UNIX to MacOS to Windows. Besides, it's a program, not a document. Applications and content are inherently different.
It's just a feature. Not a conspiracy. Not a means of taking over the world. >>>>>> If you trust Microsoft that much, then that's you're business. However, as a user of an open source OS, and as a user that cares about freedom and competition in the software market, I simply can't ignore Microsoft's track record and blindly hope for the best.
Though it is not quite the same, this sounds an awfull lot like the menu-hiding 'feature' in MS Office. It's one of the first things I always turn off;). >>>> Not really. I agree that the menu hiding is confusing. I'm talking about right-click context menus. They are inherently a shortcut mechanism, and should be limited to only a handful of entries in total, so the user can quickly access one. Konqueror (and IE) have more than a dozen entries in their context menus. That's just too much.
I think the maximize window functionality found in all of todays GUIs does this excellently, wouldn't you agree? >>>>>> There is really no reason to have the user manually manage windows. First, it's another level of training you have to give the user. Second, it's irritating. Most of the time, I want my window maximized, it's only some of the time that I want to see more than one at once. The common case should be optimized, not the general case.
I fail to see what tabs accomplish that the Windows task bar or OS X dock doesn't. Tabs are used for switching between windows of a specific application, nothing more, nothing less. In fact, since tabs are an alternative way of switching between windows, the combination of the two (tabs and taskbar/dock) complicates matters even more. >>>>> Tabs are a very powerful feature. They can clearly switch between different "views" of the same application. In my scheme, tabs would be used both for switching between top-level application windows, and views of the same application. There would be no taskbar. Look at something like Outlook. The icons on the left-hand bar are an implementation of the "tab-view" concept. While the icon text sucks, in my experience users find the concept easy to understand. It minimizes the amount of information they have to concentrate on at once.
Showing and hiding UI elements does not speed up pattern recognition, but slows it down, since the pattern keeps changing all the time. >>>>> Not really. Not everything needs to be in the "working set" at the same time. If I'm looking for an application to switch to, I don't need to see anything else. While it would undoubtedly require some training, by minimizing the other metaphors that need to be understood, this training might be feasible.
I've been thinking of this for awhile now. I've come to the conclusion that this is (at least partly) a method to prevent the inter-operation of competing OSs. Microsoft realizes that their proprietory document format isn't going to keep vendors from interoperating, not in the long run. Open Office has already made significant strides in reading Office format documents. Breaking compatibility in the format requires breaking compatibility in their Office products as well, which isn't a suitable option. Thus, embedding DRM in the format is the ideal method. Think about these points:
1) DRM can turn any open format, like PDF or XML, instantly into a closed format. If a competing product can't use the DRM technology, it can't read the document, even if it could do it theoretically.
2) Embedding DRM into the document format itself makes little sense, other than for the above reason. Why not just integrate proven and time-tested encryption algorithms into Office suites? If a user wants to secure a document, they can click the "secure" button, and the office suite could encrypt the document using something like PGP. That should provide enough security for most businesses, and for those that it doesn't, well they have their own security methods anyway.
3) In light of the first two reasons, it's quite clear that DRM in the document format can easily be used to turn open content into Windows content. This is especially true if the format defaults to something like "DRM on, no protection" in which the DRM mechanism would be enabled, but no access checks would be performed. To the clueless user, this would seem like the standard mechanism we have today, but these documents would not be viewable on platforms that do not have the DRM mechanism.
4) To tie it all together, the DMCA provides Microsoft with a degree of legal protection. While it is perfectly legal to reverse engineer Microsoft's document formats, it probably would not be legal to break the encryption, even if it was with the purpose of gaining interoperability.
Of course, this could be an entirely benign move on Microsoft's part. But in this day and age, and with Microsoft's track record, are you really willing to take the chance?
First, let me say that I hate the direction GNOME is moving. It's just plain not as configurable as KDE, and what configurability their is, is buried in a rather opaque registry.
Second, I think the larger problem is not so much configurability, but complexity. It's not a matter of how many options are there, but how those options are presented. The main problem with human beings is not that they can't deal with large amounts of data, but that they can only deal with small pieces of a large data set at a given time.
This problem encompasses not just configuration, but all desktop GUIs (even OS X). The Windows/Menus/Icons/Pointer is just too complex. There are too many widgets, too many places to access functionality, too many places to display information. For those of you on Windows (I feel your pain) fire up Windows Media Player. The interface is a nightmare. It's even hard for me to use! There are at least six different locations where controls are located. Information is displayed in multiple locations. It's just a mess. Then fire up Word. There are dozens of icons that have absolutely no recognizable meaning. The problem reaches critical mass in a program like AutoCad (I'm an engineering major, so I have a vested interest in seeing this UI mess disposed of as soon as possible!) Dozens of icons, all similar looking. Context menus that have no relation to the object being clicked on. Weird interactions between the command-line, menus, and context menus.
This interface complexity hinders not only ease of use, but efficiency. Think of what happens when your PC starts using the swap file. It spends all it's time trashing the hard drive instead of doing real work. When a user is confronted with all the gidgets in modern UIs, their thought process and efficiency slows to a crawl.
To ease the interface mess, we need to rethink how humans interact with the GUI. A next-gen GUI would have the following features:
1) Little to no "widgetry" visible on-screen. The user should be able to concentrate on what he's working on, rather than be distracted by UI information. Think "vi" vs "MS Word."
2) One point of access to functionality. Like "vi's" command line or Houdini's keyboard-menus.
3) Succinct context menus. Context menus should have no more than a half a dozen entries, and should only function as shortcuts for functionality accessible from the "common access point."
4) No more windows. Overlapping windows are just confusing and require too much user intervention. A next gen GUI should be based on a full-screen application mechanism. For the relatively few times when more than one application needs to be visible at the same time, mechanisms need to be provided to facillitate this. This is an example of optimizing for the common case.
5) More use of tabs. Tabs are a surprisingly easy mechanism for users to pick up. Note that all the navigation menus on the web are a version of the essential "tab view" concept.
6) Larger UI elements. Since the UI would only show the elements absolutely necessary at the moment, UI elements could be large, which greatly speeds up pattern recognition in the human brain.
7) More use of color. Humans are remarkably sensitive to color coding, but for some odd reason, current GUIs only use color for asthetic purposes.
8) More use of text. The human brain is a language processing machine. Current GUIs rely far too much on metaphors and other elements that require user training, instead of just plainly telling users what's going on. Take menu entries. Instead of being short and cryptic, they should be detailed and explanatory. Who cares if that makes the menu bigger. Are you looking at something else while you're reading the menu?
9) Seperation of "background" tasks from "foreground" tasks. KDE is doing a great job of this with it's notification bar programs for noatun and kopete.
10) More powerful application management. The user shouldn't have to manually manage applications. Some intelligence should be applied to keep running applications easily accessible. For example, when I'm doing research papers, the "taskbar" concept just plain can't handle the explosion of application windows.
11) Global workflow enhancers. Many of the workflow enhancers found in high-end applications like Maya and Photoshop, like info-bars, undo-histories, etc, could easily be applied to applications in general. A consistent set of workflow enhancers would greatly help efficiency, while reducing the burden on application developers to write these systems.
The overall point of this concept is to streamline the computer/human interface. It reduces the dependence on metaphors, which is hard for users to inderstand, and allows them to interact more directly. An implementation of this concept probably would not be intuitive. (BTW, intuitiveness is a sham. Nothing is intuitive, except the three built-in human actions, sucking, grasping, and cuddling.) It would require a modicum of user training. But with the large numbers of locations where user training is available, such as workplaces and schools, along with the rising number of computer-educated sons/daughters/grandchildren/friends/etc, such training should be acessible. Most importantly, teh features of the system are such that a minimum number of concepts are required to understand the whole system. Once those concepts are understood, the user can proceed without further intervention.
The problem is that Windows and windows programs were not designed to be skinned. Linux desktops were designed from the ground up for skinning. As a result, they pay careful attention to the color style of the skin. For example, Qt has a class that defines the color properties of a theme so applications can take the theme into account. Also, I have a feeling that KDE themes are much more powerful than external themes because they have access to the internals of the GUI, and can insert specific code to patch certain behaviors (through the Qt polish()/unpolish() mechanism). I run KDE almost all the time, and pretty much every KDE theme looks perfectly native, from.NET to Liquid (two *very* different styles).
You gotta love Ars. In a day and age when some people purporting to be geeks still belive that a "G4 is up to twice as fast as the fastest Pentium 4," and when tech articles and writing (even in the Linux world, and in Maximum PC) have been incredibly dumbed down, Ars Technica still isn't afraid to have in depth, technical articles. Their articles have words like "pipeline" and "execution unit" and their CPU articles (in particular the PC vs PS2 one) are very informative. Good job guys!
I brought up my laptop to say that my laptop runs circles around an OS X workstation. I forgot to write workstation at the end. The OS X laptops really aren't meant for workstation-level use.
Logically, windows are the central aspect of modern UIs. But in terms of computing power, windows aren't the major burden. It's the stuff *inside* the windows that takes a lot of CPU to draw. Let me see if I can explain the model:
OS X without Quartz Extreme --
Each application has a chunk of memory for it's window. It draws, via the CPU, into this memory using Quartz 2D. The graphics card is largely used for quickly drawing bitmaps. It does not accelerate drawing of any of Quartz2D's vaunted vector graphics. Quartz Compositor then takes all of these windows, and with the CPU, does the shadow and transparency effects, and draws the final result into the screen.
OS X with Quartz Extreme --
Each application has a chunk of memory for its window. It draws, via the CPU, into this memory using Quartz 2D. The graphics card is largely used for quickly drawing bitmaps. It does not accelerate drawing of any of Quartz2D's vaunted vector graphics. Quartz Compositor then takes all of these windows, turns them into textures. Then it sends them to the graphics card, which does the transparency and shadow effects, and draws the results onto the screen.
Now, Quartz Extreme is a big improvement in OS X, because previously, it was the CPU that had to recomposit all the windows everytime one of them changed. However, in the computing world overall, it's not really a big deal. Other window systems don't do the compositing step (which is useful only for window-transparency and shadows) so something like Quartz Extreme wouldn't have any effect at all. Now, Longhorn and EVAS (Enlightenment 17) are actually hardware accelerated desktops. In EVAS, everything is done via the GPU. Take a look at the AGG-2 page. Look at the screenshots. In EVAS or Longhorn, those drawings could be accelerated via OpenGL (which was designed for vector graphics!) In OS X, they would have to be done via Quartz 2D on the CPU.
The Athlon 64 probably won't have more registers than a P4. The P4 has 128 internal registers that the 8 physical registers map to. The Athlon 64 will have 16 visible registers, but the internal register set that they map to might not be any larger. The main benefit is better optimizations thanks to the larger visible register set. The Athlon also has more (seperate) XMM (SSE) registers, but the MMX registers are still shared with the FPU registers.
The 64-bits should really have no effect on performance. What *should* improve performance on the Athlon 64 (with respect to UT2k3)
1) More user-visible registers. The Athlon-64 probably doesn't have any more physical registers than a P4 (which has 128 of them) but allowing 16 to be visible to the compiler should let the compiler optimize better. 2) Memory subsystem. The Athlon 64 has a memory subsystem derived from the Alpha EV7. Since these games are very memory-bandwidth bound, this should be a big speedup. 3) Optimizations in the CPU core. With each release, the vendor can make optimizations that improve overall instruction throughput.
Slashdot Mirror
One, I don't consider C++ to be a strongly typed language. Ada or Modula-2 yes, but not C/C++. The typing information is there, but it's easily bypassed, and often MUST be to do normal operations.
>>>>>>
Whoa there. Name *one* example where you *have* to do a typecast in properly written C++ code. Hell, just name one example where it is significantly cleaner/easier (to a C++, not C, programmer!) to do a cast rather then doing it the "right" way. Note, dynamic_cast, const_cast, and static_cast don't count, since they're type-checked, safe casts. Only reinterpret_cast here!
Um, an automatic conversion from 'int' to 'float' does not imply the language is not strongly typed. An 'int' and a 'float' represent the same concept (a number) and have similar representations at the machine level. As for the typedef, a typedef does not create a new type (if it did it'd be called 'typecreate'). It simply creates a shortened alias for a type. In the second statement, both 'Date' and 'int' are the same type, thus there is no conversion going on, thus the "strong-typed'ness" of the language isn't even being called into question.
PS> Introducing a new type with 'typedef' would be a major pain. Consider the case of template classes, which often are typedef'ed into a more readable representation:
typedef std::vector<int> IntVector;
typedef std::vector<int> NumberVector;
void foo(IntVector& iVec);
Clearly, in a strongly typed language, foo should be able to take either an IntVector or a NumberVector, because they're the same type! Typedefs, in C++, are largely a convenience mechanism, and thus has semantics that lean towards convenience. Now, you could argue that there needs to be a 'typecreate' keyword that creates a new type out of an existing one, but that's another kettle of fish. The real question is, why not just use the existing type if it suits your purposes as is?
Correction. C does not have strong type checking. C++ has quite strong type checking, but provides a decent set of automatic conversions and provides an "out" for those that need it. reinterpret_cast(&foo) does not magically slip into your code. Not only is it pretty long to type, it's hard to spell "reinterpret." If it's there, you did it on purpose. And if you did it on purpose, the language should get the f**k out of your way and let you do it.
Actually, I studied OS design (and yes, I do read linux-kernel), which is the reason I am not as hostile to x86 as some people. You can say what you will about the elegance of the architecture, but in certain caes, it's just plain friendlier than others to the OS programmer. The VM model is relatively simple, it doesn't do weird stuff with memory-mapped I/O, it jumps through tons of hoops internally to keep interrupt semantics simple, etc. Once you wrap your head around segmentation (which is set it and forget it nowadays) it's pretty smooth sailing.
Hm. In theory, the ICH3-M southbridge in my Inspiron has an I/O APIC. Neither Linux nor WinXP enable it, though.
Um, what about this implies that you won't use the MMU? I'd prefer an object-level protection system like in the AS/400, but the MMU can easily be used to protect something like this.
It wouldn't matter. Only Apple can get the 1.8" drives at the moment, so everything else will be bigger. The iPod just slides under the "too big to pocket" limit. Even something just slightly larger (the Nomad Zen, for example) is too big.
The OGG bit might be a kicker, but if you can afford to re-rip, GET AN IPOD. The 20GB model is supposed to be priced-dropped to $400 this week. You'll appreciate the big (small) difference in size.
I've heard of all the problems in Africa, Kashmir, China, and the Philipines. However, those are really not as bad as the situation in the Middle East. The stuff about Israel is an oversimplification. If foreign policy were that simple, the US government wouldn't have so many problems with it. But I'll bite. Why do we support Israel so strongly? We weren't the only country involved in its creation. Could it be because it is powerful, US friendly democracy (kinda) in a region where we (thaks to oil) need influence and stability? Remember, nations have no friends, just interests.
x86 code is famously compact. According to the x86-64 docs, the average instruction length on x86 is about 3.2 bytes, significantly less than the 4 bytes of all 32-bit/64-bit RISC chips. Now ARM chips can have smaller code, but they do it through a 16-bit instruction set called ARM Thumb.
Memory mapping a harddrive won't make it faster to access, I agree. But simplifying parts of the code is a very big win. By memory mapping the HD, you can just let the page cache handle the I/O.
64-bit CPUs are really an OS designer's wet dream. There are lots of things (bounce buffers, dynamic RAM map, prelinking headaches) that just go away with a 64-bit address space. You can just map all RAM permenently, prelink all binaries to a unique address, and move on with your life (or lack thereof). I was thinking the other day, that with the move to database oriented filesystems like Reiser4 and LonghornFS (for lack of a better name) that the time is ripe for some of that OO research from the 80's and 90's to kick in. The gist is that instead of the basic abstraction being files with a strict naming hierarchy, the basic abstraction is a set of objects with a very flexible database index. Throw in object persistence, and you've got yourself a very elegant setup, with basically and OODBMS at the core of the system. However, straightforward (fast) implementations of the scheme blow away a 4GB address space. For something like this, you really want to be able to mmap() a 120GB harddrive and remove a whole lot of intervening hacks.
Actually, the modern PC architecture is just that, throughly modern.
1) The CPU: x86? Who cares? Even the Power4 does instruction-level translation, and advances like the trace cache take decode out of the hot path. In the end, x86 is just a nice, compact, widely supported bytecode. Outside of instructions, PC processors are very modern. Highly superscaler, highly pipelined, *very* high performance.
2) The chipset: This isn't your ISA system anymore. CPU -> chipset and chipset -> Memory interrconnects will be hitting 6.4 GB/sec by the end of the year. The Athlon 64 will have an integrated memory controller, just like the UltraSPARC. I/O hangs of the PCI bus, which is not a bottleneck given current systems. And when it does become a bottleneck, solutions like Hypertransport are already ready and working. Peripherals now hang off advanced busses like USB and Firewire, while traditional I/O methods are relegated to a tiny (cheap!) Super I/O chip. ISA is finally dead (the new Dells don't ship with ISA slots). The only thing we can't seem to get rid of is the infernal 8239 interrupt controller. The I/O APIC has been around for ages now. VIA has integrated them for years. Intel is finally getting around to putting them in, but is doing a half-assed job of it. My Inspiron has an 845 chipset, which theoretically has an IO-APIC, but it seems disabled for some reason.
3) The firmware: OSs today ignore the BIOS anyway. They're only in place for booting and SMM mode. ACPI has replaced most of what the BIOS used to be used for. Just this month, Intel said that EFI (used in the Itanium) will finally replace the PC BIOS, and bring with it a host of new features like support for high-resolution booting modes, network drivers, advanced debugging, etc.
Not only is sustainable energy good for the environment, but it's good for politics. The key question is: why do Middle Eastern terrorists, and many Middle Eastern non-terrorists, hate the West? The easy, overly simplistic, and thus popular, answer is because they're insane fundementalists who have a huge amount of pent up anger and will go after anything. This is no doubt partially true. Insane fundementalism is unfortunately a bane of human existance. However, the current level of animosity between two large segments of the world's population is too large to attribute soley to insanity. After all, the same level of conflict doesn't exist between the western countries and Asia, or them and Africa. A more encompassing answer is that terrorists have immense hatred because they're fundementalists, and the our continual meddling in the business of the Middle East just fuels their fire and gives them an excuse to take it out on us. Now, why do we continually meddle in the business of the Middle East? The answer is very clear. It's all about the oil. If it were not for oil, we would have absolutely no reason to be involved. It might very well be that without the stabilizing influence of western countries, the Middle East would degenerate into a mass of feuding, warring countries, but that was precisely the state of Europe for several centuries, and it would be supremely sanctimonious to believe that it would be in their best interest to be stabilized. It can be argued that such a state of existence is a natural phase in a region's progression, and that without such a phase, the real benifets of regional peace cannot be appreciated. Unfortunately, we cannot afford to base our decisions on philosophical ideals about the progression of civilizations. We need the oil, and we are pushed into a certain course of action in order to secure that oil. Rampant terrorism is the unfortunate consequence of a combination of impugned racial, regional, and national pride, and the latent hostility and fundementalism present in all human societies. Thus, Mr. Blair is more correct than it seems at first. Not only are sustainable energy sources less susceptible to terrorist attack, but moving to such sources greatly lessens the chances of such attack to begin with.
a) a $.69 Mead notebook and a Bic or :)
>>>>>>>>
My dad has more contacts than most people have MP3s. He has something like a dozen scheduled phone calls and meetings a day. His situation is quite a common one. He replaced his overflowing 2-inch thick contact book with a 1/2-inch thick Sony Clie. He spends less time searching for names and numbers, and the thing gives a nice alert when he has an appointment. Of course, I spend a a lot of time troubleshooting the damn thing, but I figure he saves a good deal more time by using it than I waste fixing it
Crypto is by an large open and implementable on any operating system. A properitory DRM mechanism is not.
That's the point. You can't open up a PGP encrypted file unless you have PGP. You can't view secure web pages unless you have the crypto in your browser. You can't read Office DRM stuff unless you have Office.
>>>>>>
Interface vs implementation. PGP is an interface. SSL is an interface. There are many implementations of each. Office is itself an implementation. Tying a document to an interface is a technical necessity. Tying a document to an implementation is at best a stupid design decision, and at worst a market control tactic.
No one has to buy Office 2003. No one who does get Office 2003 has to use DRM. Anyone who does use the DRM is going to know that the readers of the data will need Office, and they'll be okay with that. If they weren't they wouldn't use it.
>>>>>>>
You give users far too much credit. People will buy Office 2003, if only because it's pretty much included with most computer sold at places like CompUSA. Second, if Office 2003 ships with DRM on by default (but with no access checks being performed), then they'll be using DRM whether they want to or not, because they don't know any better. It's the third point that's the kicker. Let me reiterate your statement:
Anyone who does use the DRM is going to know that the readers of the data will need Office
>>>>>>>>>>
That's not true right now. Right now, there exist numerous tools to open Office documents even if you don't have Office. Office DRM would prevent that, and give Microsoft more control of the document format. *That's* why this is a dangerous "feature."
Your complaint about it being Windows-only is bork. An Office DRM user is intending the reader of his/her document to be using Office.
>>>>>
Well, most users don't know that. They just use it without a second though. User's who use Office aren't clear that their being incompatible with the rest of the world. And a key thing is that they're really not. I can read an Office document in a pinch. Not in the age of Office DRM Edition.
It's the same way that the authors of Bash are intending the user of their app to be running Unix.
>>>>>
No. Bash runs on everything from UNIX to MacOS to Windows. Besides, it's a program, not a document. Applications and content are inherently different.
It's just a feature. Not a conspiracy. Not a means of taking over the world.
>>>>>>
If you trust Microsoft that much, then that's you're business. However, as a user of an open source OS, and as a user that cares about freedom and competition in the software market, I simply can't ignore Microsoft's track record and blindly hope for the best.
Though it is not quite the same, this sounds an awfull lot like the menu-hiding 'feature' in MS Office. It's one of the first things I always turn off ;).
>>>>
Not really. I agree that the menu hiding is confusing. I'm talking about right-click context menus. They are inherently a shortcut mechanism, and should be limited to only a handful of entries in total, so the user can quickly access one. Konqueror (and IE) have more than a dozen entries in their context menus. That's just too much.
I think the maximize window functionality found in all of todays GUIs does this excellently, wouldn't you agree?
>>>>>>
There is really no reason to have the user manually manage windows. First, it's another level of training you have to give the user. Second, it's irritating. Most of the time, I want my window maximized, it's only some of the time that I want to see more than one at once. The common case should be optimized, not the general case.
I fail to see what tabs accomplish that the Windows task bar or OS X dock doesn't. Tabs are used for switching between windows of a specific application, nothing more, nothing less. In fact, since tabs are an alternative way of switching between windows, the combination of the two (tabs and taskbar/dock) complicates matters even more.
>>>>>
Tabs are a very powerful feature. They can clearly switch between different "views" of the same application. In my scheme, tabs would be used both for switching between top-level application windows, and views of the same application. There would be no taskbar. Look at something like Outlook. The icons on the left-hand bar are an implementation of the "tab-view" concept. While the icon text sucks, in my experience users find the concept easy to understand. It minimizes the amount of information they have to concentrate on at once.
Showing and hiding UI elements does not speed up pattern recognition, but slows it down, since the pattern keeps changing all the time.
>>>>>
Not really. Not everything needs to be in the "working set" at the same time. If I'm looking for an application to switch to, I don't need to see anything else. While it would undoubtedly require some training, by minimizing the other metaphors that need to be understood, this training might be feasible.
I've been thinking of this for awhile now. I've come to the conclusion that this is (at least partly) a method to prevent the inter-operation of competing OSs. Microsoft realizes that their proprietory document format isn't going to keep vendors from interoperating, not in the long run. Open Office has already made significant strides in reading Office format documents. Breaking compatibility in the format requires breaking compatibility in their Office products as well, which isn't a suitable option. Thus, embedding DRM in the format is the ideal method. Think about these points:
1) DRM can turn any open format, like PDF or XML, instantly into a closed format. If a competing product can't use the DRM technology, it can't read the document, even if it could do it theoretically.
2) Embedding DRM into the document format itself makes little sense, other than for the above reason. Why not just integrate proven and time-tested encryption algorithms into Office suites? If a user wants to secure a document, they can click the "secure" button, and the office suite could encrypt the document using something like PGP. That should provide enough security for most businesses, and for those that it doesn't, well they have their own security methods anyway.
3) In light of the first two reasons, it's quite clear that DRM in the document format can easily be used to turn open content into Windows content. This is especially true if the format defaults to something like "DRM on, no protection" in which the DRM mechanism would be enabled, but no access checks would be performed. To the clueless user, this would seem like the standard mechanism we have today, but these documents would not be viewable on platforms that do not have the DRM mechanism.
4) To tie it all together, the DMCA provides Microsoft with a degree of legal protection. While it is perfectly legal to reverse engineer Microsoft's document formats, it probably would not be legal to break the encryption, even if it was with the purpose of gaining interoperability.
Of course, this could be an entirely benign move on Microsoft's part. But in this day and age, and with Microsoft's track record, are you really willing to take the chance?
First, let me say that I hate the direction GNOME is moving. It's just plain not as configurable as KDE, and what configurability their is, is buried in a rather opaque registry.
Second, I think the larger problem is not so much configurability, but complexity. It's not a matter of how many options are there, but how those options are presented. The main problem with human beings is not that they can't deal with large amounts of data, but that they can only deal with small pieces of a large data set at a given time.
This problem encompasses not just configuration, but all desktop GUIs (even OS X). The Windows/Menus/Icons/Pointer is just too complex. There are too many widgets, too many places to access functionality, too many places to display information. For those of you on Windows (I feel your pain) fire up Windows Media Player. The interface is a nightmare. It's even hard for me to use! There are at least six different locations where controls are located. Information is displayed in multiple locations. It's just a mess. Then fire up Word. There are dozens of icons that have absolutely no recognizable meaning. The problem reaches critical mass in a program like AutoCad (I'm an engineering major, so I have a vested interest in seeing this UI mess disposed of as soon as possible!) Dozens of icons, all similar looking. Context menus that have no relation to the object being clicked on. Weird interactions between the command-line, menus, and context menus.
This interface complexity hinders not only ease of use, but efficiency. Think of what happens when your PC starts using the swap file. It spends all it's time trashing the hard drive instead of doing real work. When a user is confronted with all the gidgets in modern UIs, their thought process and efficiency slows to a crawl.
To ease the interface mess, we need to rethink how humans interact with the GUI. A next-gen GUI would have the following features:
1) Little to no "widgetry" visible on-screen. The user should be able to concentrate on what he's working on, rather than be distracted by UI information. Think "vi" vs "MS Word."
2) One point of access to functionality. Like "vi's" command line or Houdini's keyboard-menus.
3) Succinct context menus. Context menus should have no more than a half a dozen entries, and should only function as shortcuts for functionality accessible from the "common access point."
4) No more windows. Overlapping windows are just confusing and require too much user intervention. A next gen GUI should be based on a full-screen application mechanism. For the relatively few times when more than one application needs to be visible at the same time, mechanisms need to be provided to facillitate this. This is an example of optimizing for the common case.
5) More use of tabs. Tabs are a surprisingly easy mechanism for users to pick up. Note that all the navigation menus on the web are a version of the essential "tab view" concept.
6) Larger UI elements. Since the UI would only show the elements absolutely necessary at the moment, UI elements could be large, which greatly speeds up pattern recognition in the human brain.
7) More use of color. Humans are remarkably sensitive to color coding, but for some odd reason, current GUIs only use color for asthetic purposes.
8) More use of text. The human brain is a language processing machine. Current GUIs rely far too much on metaphors and other elements that require user training, instead of just plainly telling users what's going on. Take menu entries. Instead of being short and cryptic, they should be detailed and explanatory. Who cares if that makes the menu bigger. Are you looking at something else while you're reading the menu?
9) Seperation of "background" tasks from "foreground" tasks. KDE is doing a great job of this with it's notification bar programs for noatun and kopete.
10) More powerful application management. The user shouldn't have to manually manage applications. Some intelligence should be applied to keep running applications easily accessible. For example, when I'm doing research papers, the "taskbar" concept just plain can't handle the explosion of application windows.
11) Global workflow enhancers. Many of the workflow enhancers found in high-end applications like Maya and Photoshop, like info-bars, undo-histories, etc, could easily be applied to applications in general. A consistent set of workflow enhancers would greatly help efficiency, while reducing the burden on application developers to write these systems.
The overall point of this concept is to streamline the computer/human interface. It reduces the dependence on metaphors, which is hard for users to inderstand, and allows them to interact more directly. An implementation of this concept probably would not be intuitive. (BTW, intuitiveness is a sham. Nothing is intuitive, except the three built-in human actions, sucking, grasping, and cuddling.) It would require a modicum of user training. But with the large numbers of locations where user training is available, such as workplaces and schools, along with the rising number of computer-educated sons/daughters/grandchildren/friends/etc, such training should be acessible. Most importantly, teh features of the system are such that a minimum number of concepts are required to understand the whole system. Once those concepts are understood, the user can proceed without further intervention.
The problem is that Windows and windows programs were not designed to be skinned. Linux desktops were designed from the ground up for skinning. As a result, they pay careful attention to the color style of the skin. For example, Qt has a class that defines the color properties of a theme so applications can take the theme into account. Also, I have a feeling that KDE themes are much more powerful than external themes because they have access to the internals of the GUI, and can insert specific code to patch certain behaviors (through the Qt polish()/unpolish() mechanism). I run KDE almost all the time, and pretty much every KDE theme looks perfectly native, from .NET to Liquid (two *very* different styles).
You gotta love Ars. In a day and age when some people purporting to be geeks still belive that a "G4 is up to twice as fast as the fastest Pentium 4," and when tech articles and writing (even in the Linux world, and in Maximum PC) have been incredibly dumbed down, Ars Technica still isn't afraid to have in depth, technical articles. Their articles have words like "pipeline" and "execution unit" and their CPU articles (in particular the PC vs PS2 one) are very informative. Good job guys!
I brought up my laptop to say that my laptop runs circles around an OS X workstation. I forgot to write workstation at the end. The OS X laptops really aren't meant for workstation-level use.
Logically, windows are the central aspect of modern UIs. But in terms of computing power, windows aren't the major burden. It's the stuff *inside* the windows that takes a lot of CPU to draw. Let me see if I can explain the model:
OS X without Quartz Extreme --
Each application has a chunk of memory for it's window. It draws, via the CPU, into this memory using Quartz 2D. The graphics card is largely used for quickly drawing bitmaps. It does not accelerate drawing of any of Quartz2D's vaunted vector graphics. Quartz Compositor then takes all of these windows, and with the CPU, does the shadow and transparency effects, and draws the final result into the screen.
OS X with Quartz Extreme --
Each application has a chunk of memory for its window. It draws, via the CPU, into this memory using Quartz 2D. The graphics card is largely used for quickly drawing bitmaps. It does not accelerate drawing of any of Quartz2D's vaunted vector graphics. Quartz Compositor then takes all of these windows, turns them into textures. Then it sends them to the graphics card, which does the transparency and shadow effects, and draws the results onto the screen.
Now, Quartz Extreme is a big improvement in OS X, because previously, it was the CPU that had to recomposit all the windows everytime one of them changed. However, in the computing world overall, it's not really a big deal. Other window systems don't do the compositing step (which is useful only for window-transparency and shadows) so something like Quartz Extreme wouldn't have any effect at all. Now, Longhorn and EVAS (Enlightenment 17) are actually hardware accelerated desktops. In EVAS, everything is done via the GPU. Take a look at the AGG-2 page. Look at the screenshots. In EVAS or Longhorn, those drawings could be accelerated via OpenGL (which was designed for vector graphics!) In OS X, they would have to be done via Quartz 2D on the CPU.
The Athlon 64 probably won't have more registers than a P4. The P4 has 128 internal registers that the 8 physical registers map to. The Athlon 64 will have 16 visible registers, but the internal register set that they map to might not be any larger. The main benefit is better optimizations thanks to the larger visible register set.
The Athlon also has more (seperate) XMM (SSE) registers, but the MMX registers are still shared with the FPU registers.
The 64-bits should really have no effect on performance.
What *should* improve performance on the Athlon 64 (with respect to UT2k3)
1) More user-visible registers. The Athlon-64 probably doesn't have any more physical registers than a P4 (which has 128 of them) but allowing 16 to be visible to the compiler should let the compiler optimize better.
2) Memory subsystem. The Athlon 64 has a memory subsystem derived from the Alpha EV7. Since these games are very memory-bandwidth bound, this should be a big speedup.
3) Optimizations in the CPU core. With each release, the vendor can make optimizations that improve overall instruction throughput.