Anecdotes about people "hating" the Mac menubar does not make it a bad idea. The menubar is one of the more Fitt-ically correct aspects of MacOS' interface. The menubar is always a dead end at the top of a screen. Because the cursor's movement always ends when it hits the menubar the size of the menubar is effectively infinite. A widget's difficulty to hit is determined by its distance from the cursor and size. No matter how far the cursor is from the menubar the size is infinite meaning the menubar is infinitely easy to hit from anywhere on the screen. If users can't seem to accept the fact a menubar is infinite size is easier and more efficient than a menu bar attached to a document window that is their problem.
The Wharf/Dock concept is also an easy one to argue. Both systems allow for hiding of the widget giving all the space you want for application widgets. The size of the Wharf/Dock is also a variable, you can make them tiny and still have them be effective. Their value lies not in their pixel area but in their positioning. Even if they change is size in relation to the number of open documents or applications their size is a variable of minimum change. The Wharf/Dock is always at one of the sides of the desktop, it is simplistic to develop muscle memory to hit it. If the cursor doesn't stop at the Wharf/Dock's edge the size isn't infinite but a persistant position makes up for that inefficiency. My Dock in OSX is always to the right of the screen, no matter where my cursor is the Dock is always to the left. I've developed muscle memory to find it reflexively when I want to open or switch programs. The position of the icon's isn't constant but the position of the Dock is. That feature makes the dock a very efficient control widget.
It also isn't a good idea to think of the Wharf/Dock concept as a task list. The Wharf/Dock is an iconic representation of objects on the desktop. Just as you'd glance at your desk to see a Rolodex, pad of paper, and calculator were sitting on it a glance at the Wharf/Dock can tell you in an instant your Rolodex application, word processor application, and calculator application are all open - on the desk as it were. A task list is equivilent of reading a piece of paper with an invoice of all the things on your desk.
NeXTSTEP and MacOS' interface concepts are not the end-all be-all of interface design but they are at the least efficient. Their draw is the fact they use familiar concepts to convey information to the user. Our eyes give us most of our information about the environment we're in. We get a huge percentage of our information about things we see from their physical appearance. Ergo using visual representations of data that are differentiated by their color and shape makes iconic information very efficient for us. You know what a pen does, it writes. If you saw a pen you'd recognize it as a pen and know what it was for. If you see an icon of a pen on a piece of paper you'd likely figure activating that icon would allow you to write, as picking up a pen would. Clicking a menu and seeing text that says "KWord" doesn't give you any help figuring out what a KWord is. With an icon of a paper and pen KWord's function becomes clearer. The more information in the icon, the clearer and larger it is, the faster you will recognize the icon's image and likely the faster you'll figure what KWord is supposed to do.
KDE and GNOME moving more towards the pen icon and away from the KWord text is what will make those desktops superior to Windows. Computers have extraordinarily impressive multimedia capabilities. Most desktop paradigms don't take any advantage of that fact. The paradigms are obsessed with text. Text is great when it is useful but a picture can give so much more information in a much smaller space. A 64x64 pixel area on the screen with a meaningful picture can give more information more quickly than a 64x64 area of screen filled with text.
Take for example a CPU usage monitor. You can only fill a 64x64 area of the screen with so much readabl
NeXT/OpenStep/GNUStep/Cocoa has a much better interface model than Windows. Application menus are attached to a single app modal widget instead of being stuck to individual document windows. This makes for a much more efficient interface because the application menu is always in the same place which makes it much easier to hit with a cursor. Cocoa/MacOSX takes that idea further and makes the menu widget of infinite size by sticking it at the top of the screen. Hitting the menu bar is even ergonomically simple since the top of the screen is much easier to access than the bottom.
The Wharf/Dock system in NeXT derivitives is more friendly than the Windows start menu/button bar. All the icons in the Wharf/Dock have a visual context and use large icons. This makes for much easier access to a running application. A user can identify and switch to an application easily. Both also allow icons to be permently docked to make access to the icons even quicker than via a menu. The text based nature of the Start menu slow and inefficient.
The Windows 95 interface hasn't changed but that doesn't make it the most efficient or best interface around. NeXTSTEP's interface beat the snot out of Windows 95's. A properly configured Window Maker desktop running GNUStep apps is a very good interface to try to emulate. It is quick and doesn't follow Windows 95's mistakes.
Apple has such a large hunk of the graphic design market because its workflow is much better suited to the task. Windows tends not to make a big impression with your typical Mac photoshopite because it gets in your way far too often. Windows' color matching is cheap, the keyboard shortcuts are so inefficient as to be practically useless, and the scripting environment sucks. Anybody can write an AppleScript to shortcut a task, with a little effort you can write one by hand to be even more useful. The keyboard shortcuts are obvious and easily accessible rather than modal like Windows shortcuts. ColorSync beats the pants off Windows color matching and is native to all applications.
MacOS' workflow was the draw during "dark times", Adobe merely catered to this affinity by keeping Photoshop available. The workflow of Linux is too variable to really compare to MacOS or even Windows. Every desktop environment and window manager is going to give the user a different experience. Using Nautilus or gmc or Konq make just managing files entirely different experiences. X11's color matching is a joke, even when you've got monitor specifications. The print environment is also inconsistant and iffy at best. Linux is a good replacement for Windows machines performing several duties. It is not however suddenly going to sweep Windows or MacOS under the rug just because Photoshop runs on it.
Mice don't need multiple buttons. Functionality ought to be obvious to a user by the interface's display. Contextual menus are nice shortcuts for people afraid of a keyboard but are not an effective means to control an application. When you manipulate something real you don't have a meta key you can hold down to alter the physics of your hands and arms.
If you pick something up you use your hand, if you push a button or turn a dial you use your fingers. You don't need to switch into a "pick up" or "turn dial" mode in order to complete these tasks. This is the reason the original Mac only had a single mouse button. A mouse was supposed to simulate the single action nature of your fingers and hands. Depending on what you touch the task your fingers need to accomplish are different but they always operate in the same manner.
While context menus are Fitts-ically correct they are a burden on the user. An application's commands ought to be obvious to a user. Hiding a menu in the limbo of right click land removes the obviousness of a program's functionality.
KDE and GNOME are not vastly different desktop models than Windows XP. They may have different implementations and use different back end technologies but their model is pretty much identical. All three present the "desktop" as an application itself rather than a metaphorical top of a desk. A desktop should be something you get work done on not get work done with.
Think about sitting at a real desk (sans a PC). You might have some pens, paper, a manilla folder or two, a calculator, a Rolodex, and a small calandar. None of these items are built into your desk, they merely sit on top of it. The top of the desk provides a surface for you to work on. A computer's "desktop" ought to have the same idea.
Items on a real desktop only have a limited number of functions and their shape and design give a large hint as to what they're for. The Windows application model suggests that items on a real desktop are all shaped and look the same with only labels at the top of the objects denoting a difference to an observer. A calandar "program" looks like an addressbook "program". If you couldn't see the label or window contents you'd be at a lose to tell which was which. On a real desktop a Rolodex is definitely different from a pen or calculator.
The functions of real world items are also suggested by their controls. A Rolodex goes forward and backward, it has a knob on the side to perform said action. The organization of the contents of the Rolodex is obvious. A digital Rolodex ought to be just as obvious to work. Controls to move the selection back and forth and a means to easily and obviously determine the oganization of the contents.
I think if KDE and GNOME want to expand past Windows they ought to move in the direction of context packed interfaces. Design interfaces not to look like real world items necessarily but to function as simply and directly as possible. This would also allow them to get back to the core Unix ideology of small simple programs that do one thing well. KDE and GNOME ought to be collections of tiny applications that effortlessly meld together to get a larger task accomplished. Instead of being window centric they ought to move to be more function and document centric. Menus ought to be attached to a single on-screen widget and be modal to the entire application. There's no point in having each document open in KWord having its own menubar wasting space and being inefficiently placed. A single widget to get at an application's functions is more adherent to Fits' law and more efficient overall. Muscle memory to a point on the screen is easier than needing to roam the screen with the cursor to hit a window's Edit menu.
Truly changing KDE or GNOME's interface model to one superior to Windows will make it a better long term choice to users. Retain the option to emulate the craptacular Windows interface but move beyond it.
The article is about the viability of KDE in a corporate environment. This was not a test of the viability of OpenOffice to replace Office XP or a test to see if Sally Sixpack would switch to Linux on her home PC. As it stands KDE makes a very nice showing against Windows XP in terms of user experience.
A group of users with no prior Linux or Windows XP experience were told to perform a series of tasks it is very likely they would do in a corporate setting. Users had to compose text and send e-mail, create and manage files, and copy CDs as well as other routine tasks. The users in the Windows XP group performed the tasks only a little quicker than the KDE group. Given that it is entirely likely everyone had experience with older versions of Windows or maybe even MacOS, KDE's group performing as well as they did is major brownie points for KDE's developers.
This test is a good thing to show a PHB when approaching him or her with a proposal to switch a batch of office PCs to Linux instead of upgrading to Windows XP. The test had nothing in the slightest to do with games or the viability of Linux as a replacement for the home desktop. This is yet another of your "Linux will go nowhere without games" rants that has nothing to do with the article at hand.
The entire concept of the GPL and the general meme of Linux is source availability. I think one of the most important aspects of Linux being a tool of the little folks as well as the big folks is the little folks have as much access to it as the big folks do. Debian itself is a very successful distribution of Linux specifically because the entire distro is readily available after a few choice pecks at a terminal keyboard. In short, the ability to readily download Linux makes it very accessible.
I think an important part of distributing Free as in speech information are places like UNC's ibiblio project. UNC being a good example, many universities the world over put a good deal of money into similar projects such as SunSITE. I don't think Open Source peojects would behalf as successful was it not for this extremely wide availability. While relatively cheap, for most people large amounts of storage space on top of large amounts of bandwidth are simply unavailable. Without both projects like Debian would not likely exist in their current form. Tools like apt-get wouldn't be as useful as they are if the sources list was constrained to cdrom:/cdrom and file:/mnt/nfs/debian.
How repeatable a project do you think SunSITE is, not merely in terms of mirrors but as a repository of Free information and ideas? Also what do you feel the Free software community as a whole or individually could do to better secure availability of places like SunSITE?
The perfect slashdot geek system. Impress your friends with your new ugly web terminal, complete with crappy looking keyboard and no monitor! Only $169 after mail-in *cough*ripoff*cough* rebate!
In short this is only useful to people running NFS or SMB servers in their basement/home office/garage to allow the thing to be useful. No hard drive means no long term cache. You can't save files off of it meaning either run to your normal PC to download the file or connect to previously mentioned network share to save.
It certainly seems like these web terminals are destined to the same fate as the ThinkNIC and various other web terminals. Useful to ten whole people.
I think the sample they use takes too little into account with regards to regional conditions. Sure the average commute for all the big cities in the US might be 20 miles but the important aspect is the average deviation of individual cities. Atlanta's traffic and commute is going to much different from Dallas and Los Angeles' commute.
If the average local commute is outside of the Tango's sweet spot that region isn't likely to be a big Tango market. The more places that deviate outside the Tango's sweet spot the smaller potential market it has. If their sweet spot catered a little more to specific markets I think the Tango would be a much better proposition.
If they focused on specific commuter markets I think they could sell more of their cars. They'd have a pretty big market with a Los Angeles targetted car or New York metroplex targetted car. I wouldn't bet their national sales would be over the tens of thousands of orders if that. If they focused a little more on the needs of specific regions beyond the mere 20 mile commute sweet spot I think their potential market would be a bit bigger.
While the cost per mile of the Tango is impressive compared to theo ther cars on the list the TCO of the tango if driven long distances drops considerably. If your commute involves any freeway driving at all the TCO for the tango is downright horrible. If you've got a 64 mile commute (32 there, 32 back) your battery is only going to hold out for about 16,000 miles or about 250 commutes. That isn't even a year before your battery pack needs to be replaced. Over 100,000 miles the Tango costs you more to operate than a Hummer H2 if you live somewhere like California with low power rates easily topping 15/KWh.
The sweet spot for the Tango seems to be the "average" 20 mile commuter. This sweet spot quickly erodes if you're able to carpool or if you need to transport more than one person anywhere. The 2.6 per mile for the Tango is nice if you're alone but if the 3 per mile in a Prius gets four people to work or school you're getting way more for the penny.
The Tango is a neat idea but like many other electric offerings it makes too many sacrifices to utility. The gasoline or diesel hybrids have TCO ratings as low as the Tango and much lower than the average multipassenger electric. Getting one person somewhere for the same cost as a car that can get four people there isn't very useful nor economical.
The high cost of materials coupled with the relatively low production volume is the culprit. Cars with ICEs are manufactured in enormous quantities and have entire sub-industries in place to build supporting products and components. The electric motors in kit based electric cars are adapted to be used in the cars. The motors in more "official" offerings from Ford or GM are custom built by them in low volume. In either case you've got a lot of money going into production and design you've got to recoup and then make a profit. As yet there's no real electric Model-T chassis and drive train anyone can build a car on top of.
Load the Lombard up with RAM and spend the hundred bones on a 5400rpm hard drive. If you drop the color space down to 16 bits you can run apps pretty decently on a Lombard. I ran OSX for quite a while on one. It won't run Photoshop or Maya well but it can easily handle Office v.X/AppleWorks/BBEdit/Mail/Safari/iCal/Quicktime well enough.
Hey come back here with that!
on
Kroupware Komplete
·
· Score: 5, Insightful
An aspect of Kroupware project I find really interesting is the "indirect funding" by the German government. The government said "we need features X, Y, and Z and be compatible with Outlook and Linux". The developers responded to those requests and won the contract to develop the software. I've thought for a long time this would be a really intelligent way for government agencies of any size to get the features they want out of software for a reasonable price.
It'd be cool to see a larger group commercial group offer themselves as contract coders for government projects. They can offer a product with X features to the agency, get the money to fund the development, then distribute that software back into the wild under a Free license for everyone else to benefit.
It seems a major issue with many government agencies and corporations adopting Free Software alternatives to commercial offerings is with support. No matter how good a coder a particular OS contributor is, they are not likely available 24/7 to fix a major problem or to add a particular feature. If there is a warm body at the end of a telephone who is paid to fix bugs or add features I think more institutions would adopt Free software solutions.
In particular to Krappynameware's case, the German government is pretty gung ho about Free software to begin with. Their requirements actually included Linux support and interoperability. It'd nice to see a government agency apt to use non-proprietary solutions to their software needs. Such solutions only leed to vendor lock-in and wasting of taxpayer dollars or euros.
What groups besides maybe the major Linux distributions like SuSE and RedHat and maybe Ximian provide the sort of support government agencies contract out? I obviously haven't seen many because I can only list three off the top of my head. Are there any vendors that provide those sort of services as a regular business plan?
I've seen some links like that before regarding 64-bit integer math with AltiVec so I went delving and found that awesome page. The factorX example runs PDQ on my 867MHz G4. There's also the vecLib.framework which you may or may not know about. It's got several methods for multiprescision integer math using AltiVec.
Craig also said in his paper that the 20% performance advantage the 3.2GHz P4 enjoyed over the G5 could be made up for with G5 specific optimizations made to the Jet3D code. The code tested was basically the G4 savvy version. It is interesting that even using wholly unoptimized code the G5 trounced the G4 and held up pretty well to the P4. Depending on the application I would bet the G5 could keep up with a 3.2GHz P4 in scalar FP math.
In Vector FP math the G5 is going to mop the floor with just about anything you throw at it. If you were going to use the G5 for scientific number crunching it is entirely likely you'd do your best to vectorize as much of your code as possible. For such applications the G5 enjoys a 10x performance and thus price advantage over the Xeon based workstation you priced. For some people the G5 as a number crunching workhorse is going to be a real winner, for others the Xeon is going to keep the place running. Regardless of who uses it the G5 is pretty damn impressive.
While the Tezro is a pretty impressive looking workstation, I'm really wondering what sort of market SGI has anymore. The workhorse for the heavy 3D graphics work is the VPro V12 and the 2D video is handled by the DMediaPro expansion card. Anymore a high bandwidth high capacity 2D or 3D video accelerator is not something that necessitates a über-expensive SGI workstation. That same equipment or an equivilent could be stuck in say a G5 PowerMac or Opteron based workstation. Both would be far less expensive in initial cost and depending on your existing infrastructure have a far lower TCO and a higher return on the investment.
SGI is again looking it seems only at their existing customers. The Tezro is pretty impressive when you sit it next to your old O2 or Octane but when compared to the latest and greatest from competitors it looks a little lacking. SGI now is in the position Apple was in several years ago. They're catering to their existing yet shrinking customer base rather than the new blood that they really need to be a serious player again.
Hell they would do okay with some of their old blood they've been losing steadily. Not everyone is apt to drop $20,000 on a workstation only to need another couple thousand in HD video accelerators to get something done. They've been switching to Windows and Mac solutions because of SGI's premium price. Five workstations that can each do the same HD work as your one SGI is a much better deal for the price.
I've been a huge fan of SGI since the first time I sat down at an O2. Their systems at the time beat the crap out of anything any PC vendor offered. Now $10k work of PC workstation equipment and software will do what $50k work of SGI equipment and software will do. It is nice to see the old logo on their new machines but I'm more interested in seeing some of the old value on the new machines.
The fat binary format you're talking about is less of a feature of the Mach-O format than it is a feature of NeXT/OSX's binary loader. A fat binary is a single file image with multiple Mach-O binaries inside of it. It has a header file declaring the CPU types of the binaries in the file and their offset addresses so the binary can be loaded. From there the Mach-O is loaded normally.
It would be pretty trivial for a developer to release a fat versions of their software assuming the PPC-64 port was fully functional. OSX's loader could run the native binary for whichever processor it was running on.
If you'd like to read more about the Mach-O format you can go to Apple's Dev Site and read up. There's a ton of great info there. If you up up a level you can grab that whole chapter as a PDF for later reading.
Tell that to the people who picked up Aldus PageMaker when the Mac was released. The original Mac had problems because of the paltry amount of RAM it shipped with which was why only a handful of months later they rolled out the Fat Macs. PageMaker, MacWrite, and MacPaint were pretty exceptional programs for the time. Compare MacWrite to WordPerfect PC users were running around the same time. MacWrite was the first WYSIWYG text editor available on a mass market computer which I don't really see as a novelty.
I think the $3k price tag on the 17" Powerbooks has something to do with them not flying off shelves somewhere near the speed of light. The 15" Powerbook is Apple's sweet spot in their professional portables. They're high powered and have decent sized screens with a nice weight. The 12" Powerbook is more for people like me who want something tiny and light with enough power to still get real work done, sacrificing high power and a large screen to get it. The 17" is more of a folding workstation in the olden days minicomputer sense of the word. They aren't exactly designed or marketed for mass market appeal methinks.
Uh, what? I doubt you're going to see any laptop do online editing right now. For offline work which is typically the only work to be done in the field, a Mac laptop is going to work fine for you. You can go with FCP or maybe Avid Xpress Pro with a Mojo external accelerator.
As for Avid abandoning Mac, WTF are you smoking? Avid released Symphony for OSX as well as Xpress DV and Xpress Pro. There's a whole lot of support for Macs running Avid software now, not to mention Apple's own DV/SD/HD editing, compositing, and finishing suite.
I don't really see the 970 really requiring some massive software transition that the 68k-PowerPC transition required. The 970 and the G4 share the same ISA, the differences are microarchitectural. Developers will need access to the new systems to make sure their code is going to work but as long as they are writing their code properly the 64-bit ports shouldn't require more than a recompile. I think it makes more sense for SJ's keynote to talk about the direction Apple is moving with OSX and maybe even future software projects.
I meant they build up their stock before the initial release of a product to meet up with consumer demand. They did this with the 12" Powerbook just a couple months ago. They had lots of stock waiting to be shipped to fill the massive number of orders they had for the machines, the only thing that held them back was the lack of AP Extreme cards. The Apple stores and retailers were stocking 12" Powerbooks two weeks after the MacWorld release, I had mine about that time.
Why does an eMac without a monitor make more sense than the eMac? The eMac is designed for educational and small office use, especially situations where complexity is a roving bugbear eating small children. To run on a wired network an eMac needs three cables plugged into it, Cat-5, the keyboard, and AC power. To get on a wireless network you only need AC power and the keyboard. They are simple enough anyone that can plug in a DVD player would have no trouble with them. I'd rather have the lab of eMacs to take care of.
Slashdot Mirror
Anecdotes about people "hating" the Mac menubar does not make it a bad idea. The menubar is one of the more Fitt-ically correct aspects of MacOS' interface. The menubar is always a dead end at the top of a screen. Because the cursor's movement always ends when it hits the menubar the size of the menubar is effectively infinite. A widget's difficulty to hit is determined by its distance from the cursor and size. No matter how far the cursor is from the menubar the size is infinite meaning the menubar is infinitely easy to hit from anywhere on the screen. If users can't seem to accept the fact a menubar is infinite size is easier and more efficient than a menu bar attached to a document window that is their problem.
The Wharf/Dock concept is also an easy one to argue. Both systems allow for hiding of the widget giving all the space you want for application widgets. The size of the Wharf/Dock is also a variable, you can make them tiny and still have them be effective. Their value lies not in their pixel area but in their positioning. Even if they change is size in relation to the number of open documents or applications their size is a variable of minimum change. The Wharf/Dock is always at one of the sides of the desktop, it is simplistic to develop muscle memory to hit it. If the cursor doesn't stop at the Wharf/Dock's edge the size isn't infinite but a persistant position makes up for that inefficiency. My Dock in OSX is always to the right of the screen, no matter where my cursor is the Dock is always to the left. I've developed muscle memory to find it reflexively when I want to open or switch programs. The position of the icon's isn't constant but the position of the Dock is. That feature makes the dock a very efficient control widget.
It also isn't a good idea to think of the Wharf/Dock concept as a task list. The Wharf/Dock is an iconic representation of objects on the desktop. Just as you'd glance at your desk to see a Rolodex, pad of paper, and calculator were sitting on it a glance at the Wharf/Dock can tell you in an instant your Rolodex application, word processor application, and calculator application are all open - on the desk as it were. A task list is equivilent of reading a piece of paper with an invoice of all the things on your desk.
NeXTSTEP and MacOS' interface concepts are not the end-all be-all of interface design but they are at the least efficient. Their draw is the fact they use familiar concepts to convey information to the user. Our eyes give us most of our information about the environment we're in. We get a huge percentage of our information about things we see from their physical appearance. Ergo using visual representations of data that are differentiated by their color and shape makes iconic information very efficient for us. You know what a pen does, it writes. If you saw a pen you'd recognize it as a pen and know what it was for. If you see an icon of a pen on a piece of paper you'd likely figure activating that icon would allow you to write, as picking up a pen would. Clicking a menu and seeing text that says "KWord" doesn't give you any help figuring out what a KWord is. With an icon of a paper and pen KWord's function becomes clearer. The more information in the icon, the clearer and larger it is, the faster you will recognize the icon's image and likely the faster you'll figure what KWord is supposed to do.
KDE and GNOME moving more towards the pen icon and away from the KWord text is what will make those desktops superior to Windows. Computers have extraordinarily impressive multimedia capabilities. Most desktop paradigms don't take any advantage of that fact. The paradigms are obsessed with text. Text is great when it is useful but a picture can give so much more information in a much smaller space. A 64x64 pixel area on the screen with a meaningful picture can give more information more quickly than a 64x64 area of screen filled with text.
Take for example a CPU usage monitor. You can only fill a 64x64 area of the screen with so much readabl
That is just a sad cop out.
NeXT/OpenStep/GNUStep/Cocoa has a much better interface model than Windows. Application menus are attached to a single app modal widget instead of being stuck to individual document windows. This makes for a much more efficient interface because the application menu is always in the same place which makes it much easier to hit with a cursor. Cocoa/MacOSX takes that idea further and makes the menu widget of infinite size by sticking it at the top of the screen. Hitting the menu bar is even ergonomically simple since the top of the screen is much easier to access than the bottom.
The Wharf/Dock system in NeXT derivitives is more friendly than the Windows start menu/button bar. All the icons in the Wharf/Dock have a visual context and use large icons. This makes for much easier access to a running application. A user can identify and switch to an application easily. Both also allow icons to be permently docked to make access to the icons even quicker than via a menu. The text based nature of the Start menu slow and inefficient.
The Windows 95 interface hasn't changed but that doesn't make it the most efficient or best interface around. NeXTSTEP's interface beat the snot out of Windows 95's. A properly configured Window Maker desktop running GNUStep apps is a very good interface to try to emulate. It is quick and doesn't follow Windows 95's mistakes.
Apple has such a large hunk of the graphic design market because its workflow is much better suited to the task. Windows tends not to make a big impression with your typical Mac photoshopite because it gets in your way far too often. Windows' color matching is cheap, the keyboard shortcuts are so inefficient as to be practically useless, and the scripting environment sucks. Anybody can write an AppleScript to shortcut a task, with a little effort you can write one by hand to be even more useful. The keyboard shortcuts are obvious and easily accessible rather than modal like Windows shortcuts. ColorSync beats the pants off Windows color matching and is native to all applications.
MacOS' workflow was the draw during "dark times", Adobe merely catered to this affinity by keeping Photoshop available. The workflow of Linux is too variable to really compare to MacOS or even Windows. Every desktop environment and window manager is going to give the user a different experience. Using Nautilus or gmc or Konq make just managing files entirely different experiences. X11's color matching is a joke, even when you've got monitor specifications. The print environment is also inconsistant and iffy at best. Linux is a good replacement for Windows machines performing several duties. It is not however suddenly going to sweep Windows or MacOS under the rug just because Photoshop runs on it.
Mice don't need multiple buttons. Functionality ought to be obvious to a user by the interface's display. Contextual menus are nice shortcuts for people afraid of a keyboard but are not an effective means to control an application. When you manipulate something real you don't have a meta key you can hold down to alter the physics of your hands and arms.
If you pick something up you use your hand, if you push a button or turn a dial you use your fingers. You don't need to switch into a "pick up" or "turn dial" mode in order to complete these tasks. This is the reason the original Mac only had a single mouse button. A mouse was supposed to simulate the single action nature of your fingers and hands. Depending on what you touch the task your fingers need to accomplish are different but they always operate in the same manner.
While context menus are Fitts-ically correct they are a burden on the user. An application's commands ought to be obvious to a user. Hiding a menu in the limbo of right click land removes the obviousness of a program's functionality.
KDE and GNOME are not vastly different desktop models than Windows XP. They may have different implementations and use different back end technologies but their model is pretty much identical. All three present the "desktop" as an application itself rather than a metaphorical top of a desk. A desktop should be something you get work done on not get work done with.
Think about sitting at a real desk (sans a PC). You might have some pens, paper, a manilla folder or two, a calculator, a Rolodex, and a small calandar. None of these items are built into your desk, they merely sit on top of it. The top of the desk provides a surface for you to work on. A computer's "desktop" ought to have the same idea.
Items on a real desktop only have a limited number of functions and their shape and design give a large hint as to what they're for. The Windows application model suggests that items on a real desktop are all shaped and look the same with only labels at the top of the objects denoting a difference to an observer. A calandar "program" looks like an addressbook "program". If you couldn't see the label or window contents you'd be at a lose to tell which was which. On a real desktop a Rolodex is definitely different from a pen or calculator.
The functions of real world items are also suggested by their controls. A Rolodex goes forward and backward, it has a knob on the side to perform said action. The organization of the contents of the Rolodex is obvious. A digital Rolodex ought to be just as obvious to work. Controls to move the selection back and forth and a means to easily and obviously determine the oganization of the contents.
I think if KDE and GNOME want to expand past Windows they ought to move in the direction of context packed interfaces. Design interfaces not to look like real world items necessarily but to function as simply and directly as possible. This would also allow them to get back to the core Unix ideology of small simple programs that do one thing well. KDE and GNOME ought to be collections of tiny applications that effortlessly meld together to get a larger task accomplished. Instead of being window centric they ought to move to be more function and document centric. Menus ought to be attached to a single on-screen widget and be modal to the entire application. There's no point in having each document open in KWord having its own menubar wasting space and being inefficiently placed. A single widget to get at an application's functions is more adherent to Fits' law and more efficient overall. Muscle memory to a point on the screen is easier than needing to roam the screen with the cursor to hit a window's Edit menu.
Truly changing KDE or GNOME's interface model to one superior to Windows will make it a better long term choice to users. Retain the option to emulate the craptacular Windows interface but move beyond it.
The article is about the viability of KDE in a corporate environment. This was not a test of the viability of OpenOffice to replace Office XP or a test to see if Sally Sixpack would switch to Linux on her home PC. As it stands KDE makes a very nice showing against Windows XP in terms of user experience.
A group of users with no prior Linux or Windows XP experience were told to perform a series of tasks it is very likely they would do in a corporate setting. Users had to compose text and send e-mail, create and manage files, and copy CDs as well as other routine tasks. The users in the Windows XP group performed the tasks only a little quicker than the KDE group. Given that it is entirely likely everyone had experience with older versions of Windows or maybe even MacOS, KDE's group performing as well as they did is major brownie points for KDE's developers.
This test is a good thing to show a PHB when approaching him or her with a proposal to switch a batch of office PCs to Linux instead of upgrading to Windows XP. The test had nothing in the slightest to do with games or the viability of Linux as a replacement for the home desktop. This is yet another of your "Linux will go nowhere without games" rants that has nothing to do with the article at hand.
The entire concept of the GPL and the general meme of Linux is source availability. I think one of the most important aspects of Linux being a tool of the little folks as well as the big folks is the little folks have as much access to it as the big folks do. Debian itself is a very successful distribution of Linux specifically because the entire distro is readily available after a few choice pecks at a terminal keyboard. In short, the ability to readily download Linux makes it very accessible.
I think an important part of distributing Free as in speech information are places like UNC's ibiblio project. UNC being a good example, many universities the world over put a good deal of money into similar projects such as SunSITE. I don't think Open Source peojects would behalf as successful was it not for this extremely wide availability. While relatively cheap, for most people large amounts of storage space on top of large amounts of bandwidth are simply unavailable. Without both projects like Debian would not likely exist in their current form. Tools like apt-get wouldn't be as useful as they are if the sources list was constrained to cdrom:/cdrom and file:/mnt/nfs/debian.
How repeatable a project do you think SunSITE is, not merely in terms of mirrors but as a repository of Free information and ideas? Also what do you feel the Free software community as a whole or individually could do to better secure availability of places like SunSITE?
The perfect slashdot geek system. Impress your friends with your new ugly web terminal, complete with crappy looking keyboard and no monitor! Only $169 after mail-in *cough*ripoff*cough* rebate!
In short this is only useful to people running NFS or SMB servers in their basement/home office/garage to allow the thing to be useful. No hard drive means no long term cache. You can't save files off of it meaning either run to your normal PC to download the file or connect to previously mentioned network share to save.
It certainly seems like these web terminals are destined to the same fate as the ThinkNIC and various other web terminals. Useful to ten whole people.
I think the sample they use takes too little into account with regards to regional conditions. Sure the average commute for all the big cities in the US might be 20 miles but the important aspect is the average deviation of individual cities. Atlanta's traffic and commute is going to much different from Dallas and Los Angeles' commute.
If the average local commute is outside of the Tango's sweet spot that region isn't likely to be a big Tango market. The more places that deviate outside the Tango's sweet spot the smaller potential market it has. If their sweet spot catered a little more to specific markets I think the Tango would be a much better proposition.
If they focused on specific commuter markets I think they could sell more of their cars. They'd have a pretty big market with a Los Angeles targetted car or New York metroplex targetted car. I wouldn't bet their national sales would be over the tens of thousands of orders if that. If they focused a little more on the needs of specific regions beyond the mere 20 mile commute sweet spot I think their potential market would be a bit bigger.
While the cost per mile of the Tango is impressive compared to theo ther cars on the list the TCO of the tango if driven long distances drops considerably. If your commute involves any freeway driving at all the TCO for the tango is downright horrible. If you've got a 64 mile commute (32 there, 32 back) your battery is only going to hold out for about 16,000 miles or about 250 commutes. That isn't even a year before your battery pack needs to be replaced. Over 100,000 miles the Tango costs you more to operate than a Hummer H2 if you live somewhere like California with low power rates easily topping 15/KWh.
The sweet spot for the Tango seems to be the "average" 20 mile commuter. This sweet spot quickly erodes if you're able to carpool or if you need to transport more than one person anywhere. The 2.6 per mile for the Tango is nice if you're alone but if the 3 per mile in a Prius gets four people to work or school you're getting way more for the penny.
The Tango is a neat idea but like many other electric offerings it makes too many sacrifices to utility. The gasoline or diesel hybrids have TCO ratings as low as the Tango and much lower than the average multipassenger electric. Getting one person somewhere for the same cost as a car that can get four people there isn't very useful nor economical.
The high cost of materials coupled with the relatively low production volume is the culprit. Cars with ICEs are manufactured in enormous quantities and have entire sub-industries in place to build supporting products and components. The electric motors in kit based electric cars are adapted to be used in the cars. The motors in more "official" offerings from Ford or GM are custom built by them in low volume. In either case you've got a lot of money going into production and design you've got to recoup and then make a profit. As yet there's no real electric Model-T chassis and drive train anyone can build a car on top of.
Load the Lombard up with RAM and spend the hundred bones on a 5400rpm hard drive. If you drop the color space down to 16 bits you can run apps pretty decently on a Lombard. I ran OSX for quite a while on one. It won't run Photoshop or Maya well but it can easily handle Office v.X/AppleWorks/BBEdit/Mail/Safari/iCal/Quicktime well enough.
An aspect of Kroupware project I find really interesting is the "indirect funding" by the German government. The government said "we need features X, Y, and Z and be compatible with Outlook and Linux". The developers responded to those requests and won the contract to develop the software. I've thought for a long time this would be a really intelligent way for government agencies of any size to get the features they want out of software for a reasonable price.
It'd be cool to see a larger group commercial group offer themselves as contract coders for government projects. They can offer a product with X features to the agency, get the money to fund the development, then distribute that software back into the wild under a Free license for everyone else to benefit.
It seems a major issue with many government agencies and corporations adopting Free Software alternatives to commercial offerings is with support. No matter how good a coder a particular OS contributor is, they are not likely available 24/7 to fix a major problem or to add a particular feature. If there is a warm body at the end of a telephone who is paid to fix bugs or add features I think more institutions would adopt Free software solutions.
In particular to Krappynameware's case, the German government is pretty gung ho about Free software to begin with. Their requirements actually included Linux support and interoperability. It'd nice to see a government agency apt to use non-proprietary solutions to their software needs. Such solutions only leed to vendor lock-in and wasting of taxpayer dollars or euros.
What groups besides maybe the major Linux distributions like SuSE and RedHat and maybe Ximian provide the sort of support government agencies contract out? I obviously haven't seen many because I can only list three off the top of my head. Are there any vendors that provide those sort of services as a regular business plan?
I've seen some links like that before regarding 64-bit integer math with AltiVec so I went delving and found that awesome page. The factorX example runs PDQ on my 867MHz G4. There's also the vecLib.framework which you may or may not know about. It's got several methods for multiprescision integer math using AltiVec.
Is this enough bits for most scientific calculations?
Craig also said in his paper that the 20% performance advantage the 3.2GHz P4 enjoyed over the G5 could be made up for with G5 specific optimizations made to the Jet3D code. The code tested was basically the G4 savvy version. It is interesting that even using wholly unoptimized code the G5 trounced the G4 and held up pretty well to the P4. Depending on the application I would bet the G5 could keep up with a 3.2GHz P4 in scalar FP math.
In Vector FP math the G5 is going to mop the floor with just about anything you throw at it. If you were going to use the G5 for scientific number crunching it is entirely likely you'd do your best to vectorize as much of your code as possible. For such applications the G5 enjoys a 10x performance and thus price advantage over the Xeon based workstation you priced. For some people the G5 as a number crunching workhorse is going to be a real winner, for others the Xeon is going to keep the place running. Regardless of who uses it the G5 is pretty damn impressive.
While the Tezro is a pretty impressive looking workstation, I'm really wondering what sort of market SGI has anymore. The workhorse for the heavy 3D graphics work is the VPro V12 and the 2D video is handled by the DMediaPro expansion card. Anymore a high bandwidth high capacity 2D or 3D video accelerator is not something that necessitates a über-expensive SGI workstation. That same equipment or an equivilent could be stuck in say a G5 PowerMac or Opteron based workstation. Both would be far less expensive in initial cost and depending on your existing infrastructure have a far lower TCO and a higher return on the investment.
SGI is again looking it seems only at their existing customers. The Tezro is pretty impressive when you sit it next to your old O2 or Octane but when compared to the latest and greatest from competitors it looks a little lacking. SGI now is in the position Apple was in several years ago. They're catering to their existing yet shrinking customer base rather than the new blood that they really need to be a serious player again.
Hell they would do okay with some of their old blood they've been losing steadily. Not everyone is apt to drop $20,000 on a workstation only to need another couple thousand in HD video accelerators to get something done. They've been switching to Windows and Mac solutions because of SGI's premium price. Five workstations that can each do the same HD work as your one SGI is a much better deal for the price.
I've been a huge fan of SGI since the first time I sat down at an O2. Their systems at the time beat the crap out of anything any PC vendor offered. Now $10k work of PC workstation equipment and software will do what $50k work of SGI equipment and software will do. It is nice to see the old logo on their new machines but I'm more interested in seeing some of the old value on the new machines.
The fat binary format you're talking about is less of a feature of the Mach-O format than it is a feature of NeXT/OSX's binary loader. A fat binary is a single file image with multiple Mach-O binaries inside of it. It has a header file declaring the CPU types of the binaries in the file and their offset addresses so the binary can be loaded. From there the Mach-O is loaded normally.
It would be pretty trivial for a developer to release a fat versions of their software assuming the PPC-64 port was fully functional. OSX's loader could run the native binary for whichever processor it was running on.
If you'd like to read more about the Mach-O format you can go to Apple's Dev Site and read up. There's a ton of great info there. If you up up a level you can grab that whole chapter as a PDF for later reading.
Tell that to the people who picked up Aldus PageMaker when the Mac was released. The original Mac had problems because of the paltry amount of RAM it shipped with which was why only a handful of months later they rolled out the Fat Macs. PageMaker, MacWrite, and MacPaint were pretty exceptional programs for the time. Compare MacWrite to WordPerfect PC users were running around the same time. MacWrite was the first WYSIWYG text editor available on a mass market computer which I don't really see as a novelty.
I think the $3k price tag on the 17" Powerbooks has something to do with them not flying off shelves somewhere near the speed of light. The 15" Powerbook is Apple's sweet spot in their professional portables. They're high powered and have decent sized screens with a nice weight. The 12" Powerbook is more for people like me who want something tiny and light with enough power to still get real work done, sacrificing high power and a large screen to get it. The 17" is more of a folding workstation in the olden days minicomputer sense of the word. They aren't exactly designed or marketed for mass market appeal methinks.
Uh, what? I doubt you're going to see any laptop do online editing right now. For offline work which is typically the only work to be done in the field, a Mac laptop is going to work fine for you. You can go with FCP or maybe Avid Xpress Pro with a Mojo external accelerator.
As for Avid abandoning Mac, WTF are you smoking? Avid released Symphony for OSX as well as Xpress DV and Xpress Pro. There's a whole lot of support for Macs running Avid software now, not to mention Apple's own DV/SD/HD editing, compositing, and finishing suite.
I don't really see the 970 really requiring some massive software transition that the 68k-PowerPC transition required. The 970 and the G4 share the same ISA, the differences are microarchitectural. Developers will need access to the new systems to make sure their code is going to work but as long as they are writing their code properly the 64-bit ports shouldn't require more than a recompile. I think it makes more sense for SJ's keynote to talk about the direction Apple is moving with OSX and maybe even future software projects.
I meant they build up their stock before the initial release of a product to meet up with consumer demand. They did this with the 12" Powerbook just a couple months ago. They had lots of stock waiting to be shipped to fill the massive number of orders they had for the machines, the only thing that held them back was the lack of AP Extreme cards. The Apple stores and retailers were stocking 12" Powerbooks two weeks after the MacWorld release, I had mine about that time.
Why does an eMac without a monitor make more sense than the eMac? The eMac is designed for educational and small office use, especially situations where complexity is a roving bugbear eating small children. To run on a wired network an eMac needs three cables plugged into it, Cat-5, the keyboard, and AC power. To get on a wireless network you only need AC power and the keyboard. They are simple enough anyone that can plug in a DVD player would have no trouble with them. I'd rather have the lab of eMacs to take care of.
Other than the 17" my friend has and the ones I've seen at two Apple stores and a Fry's I haven't heard of any 17" Powerbooks shipping.