That's right, they are all propriatery. The groups who use this software are so bound into it's usage that the very idea of trying to substitude one of these programs for a Free one makes people scared.
People should still have choices available for Free and/or Proprietary applications, even after they've made the choice to use a Free OS.
I believe that RTF files are commonly labeled "filename.DOC". As long as RTF functions for you, there's no reason to get uptight or call attention to it.
That Auto Whitebalance thing is horrendous. And nothing else in the program indicates a manual white-balance.
I know I am expected to use the eyedropper in Color Levels, at the bottom under All Channels... but that only works for white and sometimes black. With few pictures having medium-grey subjects in them, how do I adjust the middle-intensity hues???
What I get is something that kinda looks white-balanced... until I put it next to the same image that was processed with a real manual white-balance like Photoshop.
I should be able to point at something white in the image, and have the dedicated white-balance function adjust hues for all intensities equally. That's what white-balance is!
1. A relatively predictable set of ABIs (for both drivers and apps)
2. Standard installation procedures
3. A defacto IDE that lands new developers smack in the middle of said platform's functionality and documentation
4. The above implemented such that ISVs can easily distribute to the platform with one file or CD-ROM distributed independantly.
5. Technical decisions that do NOT force authors to distribute through a Centralized Repository just to keep their application from breaking with each OS update.
6. A developer base that can concentrate on their ideas and customers, not on the shifting sand underneath them. Whereas 'Linux' distros have 'maintainers' that insert themselves between the end-user and the developer (and make users wrestle with faltering package databases to boot). Is the distro the right focal point for customer relationships?
'Linux' is just a kernel with several OSs built upon it. And those OSs don't constitute modern computing platforms either. They are good ways to run Apache + a databse, and one could say that LAMP is a solid platform concept. But that is all for the sever room and for web development.
Our community needs a 'LAMP' for the native, desktop environment. Is LSB Desktop up to the task?
Well... are developers creating RPMs for LSB? I've never seen such an RPM. I don't think that's even possible. How will LSB Desktop fix this?
Someone from OSDL's Project Portland invited me to join after I expressed these concerns. But even with 5 years of using Linux on my desktops, I spend most of my time on a Mac now. Maybe I will anyway; It should be interesting to find out if the community is still trying to pour sugar over warmed-up server-room procedures, or if they are going to focus on meeting user expectations.
The Audigy may have hardware mixing, but if multiple programs can coexist on a sound card with hardware mixing, software mixing can be used in the driver to achieve the same thing. dmix in ALSA does this, more or less.
However, I will concede that the equivalent experiment failed on a machine with an integrated AC97-compliant Intel chip (RealPlayer blocked everything else). There is still room for improvement. However, the software and API used by the software do not, in my estimation, need to be rewritten.
My Xandros system is also configured with alsa-oss emulation and dmix with a recent release of alsa. It still doesn't prevent apps from seizing control of the sound output. Neither do the latest releases of desktop-oriented distros like Ubuntu and PCLinux. It seems the real OSS drivers haven't been deprecated just yet, so there is still potential for conflict.
The Audigy is a relatively expensive sound card with multiple hardware channels. I know some Linux fans may think everyone should pay $50 and up for audio output (in addition to paying 8x as much for dialup hardware in the form of an external controll-endowed modem). Meanwhile create types will continue to cut their teeth on Windows and Mac, and continue to stay away from Linux because of its atrocious audio behavior.
Also,for those interested: I just checked my OS X system and there is no/dev/dsp device. Gosh I guess Apple is doomed after all! How dare they leave that "beautiful" file-oriented driver out of their operating system??
It doesn't work that way in real life. Most apps that use OSS access/dev/dsp and will lock-out the ALSA-using apps anyway.
The user must take pains to run their audio application with a wrapper prefix like 'artsdsp' or 'artsdsp -m' (depending on the kind of app). Even then, the results can be awful (timing errors and choppy audio).
This is something end-users are not likely to do. If you leave it up to the distro people, then you can't count on your audio apps working unless it comes from your distro's centralized repository (the typical Linux scenario where not much works for unskilled end-users unless they remain in the distro vendor's walled garden).
It is far better for a phone app to fail completely when someone first runs it, than to intermittantly fail the end-user by not being able to RING.
Stop facilitating broken infrastructure. Fixed the old decrepit thing, or REMOVE it!
Linux has no business preventing audio playback unless a critical app specifically requested exclusivity! Broken legacy interfaces are still BROKEN.
Re: modems, the world doesn't revolve around your personal experience. Check any discussion forum of a deskop distro and you will see loads of people pleading for help with modem drivers (yes, they are winmodems).
Ehm, and what about the several sound servers that exist? This is simply bullshit. The only problem is with older applications that use/dev/dsp directly.
You mean like Skype and Audacity?? I think you have your head in the sand.
What I find a bore is the way Desktop Linux adoption never gets anywhere, because the core community is purblind and numb to crucial usability details. Like a single standard (a platform!) that people can name when they buy/download things for their computer. Not ALSA+SMB+SATA+etc...
Applications using alsa doesn't suffer such problems. Stop using apps that use/dev/dsp directly....
You can't tell end-users that! They wouldn't know what you're talking about.
Support for any sound interface that IMPLICITLY monopolizes the soundcard must be FIXED OR REMOVED. No app should get an exclusive lock on audio unless it specifically requests that condition!
...something friendly and easy to browse when shopping for hardware. Why distro vendors are not collaborating on maintaining an HCL site is a mystery to me, as it would be a powerful tool in persuading HW vendors to offer support.
There is one at Linuxdevices.org, but its just a glorified messaging board and mostly out of date anyway.
I also find it unsettling that Linux users keep buying peripherals without checking compatability first, and end up/rewarding/ manufacturers that don't support Linux.
The real weak spots in Linux drivers are for dialup modems and Wifi cards. And Bluetooth adapters. Oh and Intel video is still broken.
Soundcard support is pretty decent, until you realize the OS often implicitly locks-out multiple apps from outputting audio... so uses involving alerts and alarms (timers, calendars, IMs, softphones, etc.) cannot be relied upon. Obviously this is also an obsctruction for musicians and DJs. But ya gotta maintain compatability with 1991 apps so the brokenness stays.
No one below the GTK+/Qt layer is paying attention to desktop use-cases, and those GUI developers are left helpless on many issues because of it. Otherwise I would not have to write the above paragraph about audio. Also, there would be stable ABIs for drivers and applications (which only removes the freedom to change the architechture BETWEEN major OS releases).
As for NDISwrapper... Thank you Microsoft, for providing a stable ABI that allows me to use my USB Wifi card on Linux!
Thats because there is no market share for apple and hackers dont waste time writting viruses for it.
There were about 40 viruses for earlier versions of the "no market share" platform.
Also virus writers are not in it for money, nor do relatively advanced coders think much about using different platforms. The pre-OS X viruses prove this.
So keep repeating the myth that large marketshare is the determining factor for infestation. It won't change the fact that OS X is more secure than Windows by design.
And if Firefox still doesn't work, you can still run Opera on Linux and use that browser's built-in agent switcher (actually I think it defaults to reporting as IE).
Its possibe you could find Opera more compatible with an IE-specific site.
If Windows is installed natively on the computer, you can run one of the freely-available Linux VMs in VMWare Player. They even have a Linux setup solely for browsing.
So if IE under WINE/Codeweavers doesn't work with the signon for some reason, then VMWare would be my next resort.
2. Basic logic: The CPU uses digital instructions to manipulate digital information. Processing occurs in volatile RAM. Describe system units (bits, bytes, K/M/GB).
3. Filesystem on HD: heirarchy, paths and supported operations (create, copy, move, del, open, close). Folders vs files, and examples of file formats (executables, different document types). HD is nonvolatile, like a file cabinet.
4. Using mouse and keyboard. Using the GUI (windows, icons, menus, etc.) to do a few basic tasks like run programs, browse and handle files, switch between programs.
5. Everything that I missed (like the cupholder)!
All told, it should be teachable to mildly-interested people within an afternoon.
Slashdot Mirror
Heheheh... OS X doesn't include Fink. That's a seperate download with a rather involved installation process.
;-)
You fanboy!
That's right, they are all propriatery. The groups who use this software are so bound into it's usage that the very idea of trying to substitude one of these programs for a Free one makes people scared.
People should still have choices available for Free and/or Proprietary applications, even after they've made the choice to use a Free OS.
I believe that RTF files are commonly labeled "filename.DOC". As long as RTF functions for you, there's no reason to get uptight or call attention to it.
This may interest you:
http://www.linuxjournal.com/article/8722
That Auto Whitebalance thing is horrendous. And nothing else in the program indicates a manual white-balance.
I know I am expected to use the eyedropper in Color Levels, at the bottom under All Channels... but that only works for white and sometimes black. With few pictures having medium-grey subjects in them, how do I adjust the middle-intensity hues???
What I get is something that kinda looks white-balanced... until I put it next to the same image that was processed with a real manual white-balance like Photoshop.
I should be able to point at something white in the image, and have the dedicated white-balance function adjust hues for all intensities equally. That's what white-balance is!
Modern computing platforms have:
1. A relatively predictable set of ABIs (for both drivers and apps)
2. Standard installation procedures
3. A defacto IDE that lands new developers smack in the middle of said platform's functionality and documentation
4. The above implemented such that ISVs can easily distribute to the platform with one file or CD-ROM distributed independantly.
5. Technical decisions that do NOT force authors to distribute through a Centralized Repository just to keep their application from breaking with each OS update.
6. A developer base that can concentrate on their ideas and customers, not on the shifting sand underneath them. Whereas 'Linux' distros have 'maintainers' that insert themselves between the end-user and the developer (and make users wrestle with faltering package databases to boot). Is the distro the right focal point for customer relationships?
'Linux' is just a kernel with several OSs built upon it. And those OSs don't constitute modern computing platforms either. They are good ways to run Apache + a databse, and one could say that LAMP is a solid platform concept. But that is all for the sever room and for web development.
Our community needs a 'LAMP' for the native, desktop environment. Is LSB Desktop up to the task?
Well... are developers creating RPMs for LSB? I've never seen such an RPM. I don't think that's even possible. How will LSB Desktop fix this?
Someone from OSDL's Project Portland invited me to join after I expressed these concerns. But even with 5 years of using Linux on my desktops, I spend most of my time on a Mac now. Maybe I will anyway; It should be interesting to find out if the community is still trying to pour sugar over warmed-up server-room procedures, or if they are going to focus on meeting user expectations.
The Audigy may have hardware mixing, but if multiple programs can coexist on a sound card with hardware mixing, software mixing can be used in the driver to achieve the same thing. dmix in ALSA does this, more or less.
However, I will concede that the equivalent experiment failed on a machine with an integrated AC97-compliant Intel chip (RealPlayer blocked everything else). There is still room for improvement. However, the software and API used by the software do not, in my estimation, need to be rewritten.
My Xandros system is also configured with alsa-oss emulation and dmix with a recent release of alsa. It still doesn't prevent apps from seizing control of the sound output. Neither do the latest releases of desktop-oriented distros like Ubuntu and PCLinux. It seems the real OSS drivers haven't been deprecated just yet, so there is still potential for conflict.
The Audigy is a relatively expensive sound card with multiple hardware channels. I know some Linux fans may think everyone should pay $50 and up for audio output (in addition to paying 8x as much for dialup hardware in the form of an external controll-endowed modem). Meanwhile create types will continue to cut their teeth on Windows and Mac, and continue to stay away from Linux because of its atrocious audio behavior.
/dev/dsp device. Gosh I guess Apple is doomed after all! How dare they leave that "beautiful" file-oriented driver out of their operating system??
Also,for those interested: I just checked my OS X system and there is no
I am so missing it. NOT.
It doesn't work that way in real life. Most apps that use OSS access /dev/dsp and will lock-out the ALSA-using apps anyway.
The user must take pains to run their audio application with a wrapper prefix like 'artsdsp' or 'artsdsp -m' (depending on the kind of app). Even then, the results can be awful (timing errors and choppy audio).
This is something end-users are not likely to do. If you leave it up to the distro people, then you can't count on your audio apps working unless it comes from your distro's centralized repository (the typical Linux scenario where not much works for unskilled end-users unless they remain in the distro vendor's walled garden).
It is far better for a phone app to fail completely when someone first runs it, than to intermittantly fail the end-user by not being able to RING.
Stop facilitating broken infrastructure. Fixed the old decrepit thing, or REMOVE it!
Linux has no business preventing audio playback unless a critical app specifically requested exclusivity! Broken legacy interfaces are still BROKEN.
Re: modems, the world doesn't revolve around your personal experience. Check any discussion forum of a deskop distro and you will see loads of people pleading for help with modem drivers (yes, they are winmodems).
/dev/dsp directly.
Ehm, and what about the several sound servers that exist? This is simply bullshit. The only problem is with older applications that use
You mean like Skype and Audacity?? I think you have your head in the sand.
What I find a bore is the way Desktop Linux adoption never gets anywhere, because the core community is purblind and numb to crucial usability details. Like a single standard (a platform!) that people can name when they buy/download things for their computer. Not ALSA+SMB+SATA+etc...
Applications using alsa doesn't suffer such problems. Stop using apps that use /dev/dsp directly....
You can't tell end-users that! They wouldn't know what you're talking about.
Support for any sound interface that IMPLICITLY monopolizes the soundcard must be FIXED OR REMOVED. No app should get an exclusive lock on audio unless it specifically requests that condition!
So the answer, as always, is that Linux must accommodate binary drivers before support can improve.
Maybe NDISwrapper is as good as it will ever get?
Windows has the stable NDIS ABI that vendors can write for (and which allows users to easily pop the driver into the system).
What does Linux have??
...something friendly and easy to browse when shopping for hardware. Why distro vendors are not collaborating on maintaining an HCL site is a mystery to me, as it would be a powerful tool in persuading HW vendors to offer support.
/rewarding/ manufacturers that don't support Linux.
There is one at Linuxdevices.org, but its just a glorified messaging board and mostly out of date anyway.
I also find it unsettling that Linux users keep buying peripherals without checking compatability first, and end up
The real weak spots in Linux drivers are for dialup modems and Wifi cards. And Bluetooth adapters. Oh and Intel video is still broken.
Soundcard support is pretty decent, until you realize the OS often implicitly locks-out multiple apps from outputting audio... so uses involving alerts and alarms (timers, calendars, IMs, softphones, etc.) cannot be relied upon. Obviously this is also an obsctruction for musicians and DJs. But ya gotta maintain compatability with 1991 apps so the brokenness stays.
No one below the GTK+/Qt layer is paying attention to desktop use-cases, and those GUI developers are left helpless on many issues because of it. Otherwise I would not have to write the above paragraph about audio. Also, there would be stable ABIs for drivers and applications (which only removes the freedom to change the architechture BETWEEN major OS releases).
As for NDISwrapper... Thank you Microsoft, for providing a stable ABI that allows me to use my USB Wifi card on Linux!
Try BitsOnWheels as an efficient Mac client. Just don't switch to the 3D view...
BitsOnWheels is an awesome client, and it uses almost no CPU when you leave the 3D display off.
I ran into a site that claimed most Mac viruses were actually MS Office macros, but they didn't show any data.
- faq/
This site shows that as of 2000, there were about 40 and were mostly Mac system-specific:
http://www.faqs.org/faqs/computer-virus/macintosh
Thats because there is no market share for apple and hackers dont waste time writting viruses for it.
There were about 40 viruses for earlier versions of the "no market share" platform.
Also virus writers are not in it for money, nor do relatively advanced coders think much about using different platforms. The pre-OS X viruses prove this.
So keep repeating the myth that large marketshare is the determining factor for infestation. It won't change the fact that OS X is more secure than Windows by design.
Yeah, of course /all/ mac users are /completely/ safe and will /never/ need protection against viruses /ever/...
As I recall, viruses were not terribly uncommon for Mac OS before OS X. Now there are none.
And if Firefox still doesn't work, you can still run Opera on Linux and use that browser's built-in agent switcher (actually I think it defaults to reporting as IE).
Its possibe you could find Opera more compatible with an IE-specific site.
If Windows is installed natively on the computer, you can run one of the freely-available Linux VMs in VMWare Player. They even have a Linux setup solely for browsing.
So if IE under WINE/Codeweavers doesn't work with the signon for some reason, then VMWare would be my next resort.
http://www.google.com/talk/otherclients.html
But thanks for the update on those clients.
If fanboys don't like comments about better alternatives for non-Windows systems, then they should just reply and say so.
I'll probably stick with Skype for now.
I'll have a crack at a basic outline of what should be taught to newbies:
1. Basic hardware functions (RAM, HD, CD, CPU, keyb, mouse, monitor, etc.)
2. Basic logic: The CPU uses digital instructions to manipulate digital information. Processing occurs in volatile RAM. Describe system units (bits, bytes, K/M/GB).
3. Filesystem on HD: heirarchy, paths and supported operations (create, copy, move, del, open, close). Folders vs files, and examples of file formats (executables, different document types). HD is nonvolatile, like a file cabinet.
4. Using mouse and keyboard. Using the GUI (windows, icons, menus, etc.) to do a few basic tasks like run programs, browse and handle files, switch between programs.
5. Everything that I missed (like the cupholder)!
All told, it should be teachable to mildly-interested people within an afternoon.