Right there, that's 90% of the reason you want to start a new software business, especially with an online service orientation. It's also the best way for the founders to make money in a medium-term timeframe. All the big companies like to buy up tech that they themselves do not possess the agility and drive to develop (yes, this even includes Google, our patron saint of searching).
And considering that the barries to entry are so low, even if came up with the killer app, you'd have competition overnight or be crushed by the big boys who have the deep pockets to tie you up in court for a decade while you try to enforce any patents you may have - and you fade away with legal costs.
Just an aside, learn a bit about the business before you spout of a full paragraph of total bullshit.
The barriers for entry are not low. Software still requires a significant and non-trivial cost.
Well, I haven't tried PyQt in about 6 months. Even if I liked it, our customer demands C++.
But, when I tried it, PyQt had some flaws. It was awkward when you wanted to make new widgets, in particular. And, maybe this is fixed, but I had a heck of a time reusing some components that my coworkers wrote.
Python is a great language with a lot of potential, but I couldn't help but feel that Qt isn't very Python-ish, and it showed in the experience. I'll check into it again.
The fact that you can suggests to me that trolltech wouldn't require moc when using c++ unless they had to.
Unless they used SWIG and MOC to do the binding.:) You don't need Moc. You could just write in all the Qt signals-slots code by hand. But who would want to? That'd totally remove the benefits of Qt.
An SB Live is whatever they want to call an SB Live. As long as it provides the same capabilities, it's still the same product. It still "works like" an SB Live. It's just cheaper to produce now, and needed a new driver mapping.
I have 0 sympathy here. Driver writers have to deal with far less change over time than software developers. Their initial job may be harder, but many drivers just don't change, or only change insignificantly.
...don't expect any fixes any time soon. Developers (like myself) work on things that are interesting and fun, IN OUR SPARE TIME. Many of us have day jobs and families and hobbies, and that time is very limited.
As a developer who has also released free software, I sympathize with that. But that doesn't mean that linux gets a magical double standard card to play whenever someone complains. If your software sucks, people will stop using it.
But I don't think the problem is manpower. I think there are a ton of smart people who have great ideas. The linux community is just slow to adopt them. Why is ALSA still pissing off Jamie Zawinsky? Because people aren't using all its cool features. It's not a technically inferior solution.
I hear all the time how Project Fu sucks because it has a bug here or is lacking a feature there, and when I ask if the bug/feature was reported, I get silence.
If you want to get bug reports, make it easy to report bugs. Set up a gmail account, hook it up to your RSS reader, and when your program crashes, detect this and offer a small form to fill out.
Or, have an active community of users, like what ESR details in his book.
The reason Linux has "fundamental issues" lies solely OUTSIDE the responsibilities of the developers working on it. It is either a vendor problem (i.e. no docs, refusal to provide docs, or threats of lawsuits), or the users (refusing to provide bug reports, testing, or details, or refusal to fund non-essential features).
This is true, if you don't have a vested interest in your software being used by anyways. If all you want to do is dump an unusable loaf of crap into a trash bin on the internet, feel free to make yet another sourceforge project that lies unrealized or unusable.
When someone tells me what I should be doing in MY SPARE TIME, I just go find something else to do.
Criticism can be hard to swallow, but as a software developer, it really pays to listen to it. If someone says, "This bug sucks!" then don't respond with, "Did you report it?" Respond with, "Consider it reported."
When MS was entered into the anti-trust suit, this was not the case. We're all talking about that legacy.
However, I might note that if you remove IE, many legacy apps do break, because they try and launch IE explicitly (and erroneously, but that's not the point).
Obviously, they can do it now. XP N is proof that it is no longer that way. But the impression is still there. Honestly, I have no idea why the EU ordered things they way they did. To me the ruling didn't seem to help much of anything, and seems very dated.
I don't think anyone here at/. is saying they shouldn't be allowed to bundle libraries. Libraries are good.
I think even uninstalling is a red herring. What pisses many people off about IE is that it seems utterly unavoidable in common use. Not only because it's an application that the system depends upon, but because it's so visible to the users.
When you run on OS X, Apple has WebCore and WebKit. They're part of the OS. Remove them and watch other apps break like dry twigs. But you can drag Safari to the trash just fine, and nothing will break. While this may be only a token gesture when 90% of your application is just a shell for the libraries, it's an important one. It's this feel that, carefully cultivated, helped MS utterly destroy Netscape back during the browser war.
The Windows Media Player is in a similar situation. The tools that other apps depend upon should be tied to quietly lurking libraries, not Microsoft applications. Imagine if DirectX was tied to a specific application, like a Microsoft 3d Modelling Program. Even dependant app becomes a form of indirect reinforcement and even advertising for the MS core apps.
I am not a template meta-programming guru. I do not have better suggestions from within C++ off the top of my head. Give me awhile to think about it.:)
But, I am baffled why TrollTech stopped at signals and slots instead of allowing real smalltalk style dynamic message sends. If you're going to introduce code generation to a framework, you need to get as much bang with the least amount of intrusion as possible.
They could have removed these awkward signals and slots, and instead introduced an Objective-C style delegation paradigm. Since they're parsing the header, why not say, "All virtual functions are now dynamically dispatchable with some simple syntax?" This pattern has been proven to work exceptionally well in staticly-typed environments. They could have even improved upon that model by allowing for multiple delegates.
I appreciate Qt as a cross-platform environment. But when I compare it to specific environments like Apple's Cocoa (or GNUStep, which is similar), or even Swing, I find that it's lacking. I understand there is a language handicap here, but that doesn't change my opinion.
Keep in mind that moment magnitude is just a convenient way to talk about seismic moment the way we would talk about the classic Richter scale magnitude.
So it's dimensionless, if I recall correctly (and wikipedia confirms this).
I suggest you read the wikipedia articles for more information. I am way out of my depth talking about geology. I only remember a few tidbits of facts from an introductory college class.
I know backwards compatability is a good thing, but at some point we need to get off the bus and say, "Standard is standard. If you break on this code, it's your problem."
It's not like we haven't had years to update these sorts of things. With TR1 incorporating some Boost features into the standard, and TR1 being the future of C++ in many eyes, it's time to stop coddling.
Since Qt is primarily a Linux, MacOSX and Windows phenomenon, I seriously doubt that TrollTech would lose sales from such a move.
I don't see how. Handling moc in the Makefiles is easy and telling that moc generates broken code is FUD, it for sure is one of the most bug-free parts of Qt.
Oh! No no! moc doesn't generate broken code. I was obviously unclear (that sentance above was supposed to be edited, but I hit Ok accidentally) and I apologize. The problem is it generates a lot of code, and it does so in nearly every Qt file. If you have an error in your code, the generated code can really confuse matters. Also, if you end up with a heap corrupution, a lot of times it segfaults in the generated code. This is not the generated code's fault, it's my error, but it does create debugging problems. It's a weakeness of all code generation systems.
But setting it up? A pain. Now, if you don't unit test your code, you can get away with qmake, no problem. But if you want to have a nice make test/check target, you're SOL, and have to go to either rolling your own or using a Qt-aware build tool, such as automake with Qt macros added in. Or, of course, you can use a controlling makefile. But this solution isn't entirely cross platform and can be confusing to people new on a project.
I find the lack of a flexiblity in their make tool particularly annoying. I've read every bit of documentation Qt3.3 has on the subject, I've asked other developers and put forth questions on mailing lists. No one seems to even think about qmake and unit tests. If they removed the need to moc source files, they'd open up the build process to more tools and make it easier to integrate into an existing project.
Source processing is part of the compiler run. Preprocessing a phase of compilation. Therefore, moc another compile phase. Do not confuse this with compile phase within the cc executable itself, that's something different and lower level.
No, using macros and moc *is* the elegant way.
No. I'm sorry, it is not. C++ is a powerful language, and while it may not be my favorite, I cannot deny that people have done amazing things with it. Check out some of the more intense Boost libraries for an example of what can be done without a preprocessor.
While that approach may be a bit more complex for the library maintainers, it certainly would make life easier for the developers, at least in my opinion.
Despite being a Qt3.3 developer, I've had almost no chance to check out any of the buzz on Qt4. What I want to know is, are they going to find a more elegant and in-language way to handle signals and slots, preferably one that does not require the use of an extra compile phase?
I'm all for meta-language programming. I love it. But not at the expense of an extra compile phase which complicates my makefiles and can introduce errors that were introduced when the generated code was inserted. I'm happy that Qt4 will finish opening up as a GPL'd library (that removes one of my biggest complaints about Qt), but are my technical concerns also going to be invalidated?
To me, this extra phase and the awkwardness of signals and slots syntax is a real weakness when compared to frameworks like Cocoa that don't need to resort to it. Now, I understand dynamic dispatch is hard in C++, but if the Boost people can get HOF-aware template-based lambdas, I'm certain that TrollTech could do better.
Not to offend anyone, because even most news agencies get this wrong, but the Richter scale was long ago deprecated for use in large quakes. You can check out the information on the Richter scale at Wikipedia, but the gist of it is that the Richter scale didn't really relate to the physical characteristics of the quake in an identifiable way.
The new system that geologists use is Moment Magnitude, which is more physically identifiable. However, it'll have values fairly similar old familiar Richter. The real benefit is that it doesn't have a cutoff limit, beyond which all earthquakes simply fall to the same value.
Just to give people a feel for the intensity of the quake, every step on the moment magnitude scale is an increase in energy by a factor of 10^1.5. Consider that a 7.0's factor is then x10^10.5, which is a pretty damn huge amount of energy, about 31622776602 times more than a magnitude 1 quake.
And how quickly did it take you to get OSX running on "diverse hardware"? Did it detect your 8-year-old video card and bleeding-edge SATA drives?
Err, seems to use SATA drives just fine. Maybe that's just me.
What I think the GP was getting at is that the inital cost of ANY system is usually quite small compared to the development and maintenance costs over time. In that regard, Linux is not free. You still pay people to take care of it. For home users, you pay with your time to take care of it. Now, certainly, Linux is a lot easier to handle than it was years ago, but it still has some fundamental issues.
I'm not saying that Linux has a higher TCO, but I am saying that Linux's TCO is nonzero, and it's not immediately obvious that it's lower than MacOSX.
Best guess of what's going to be in these desktop boxes, given what we've been seeing on/., Ars, and what little info the macdevs have leaked.
Pentium M family. Yonah maybe, but possibly something further down the M family tree (which may or may not be ready yet).
Intel's EFI. In some ways, better than OpenFirmware. In some ways, worse. We know that the new macs are not going to use OpenFirmware. It's been confirmed.
Intel's privacy stuff, as mentioned in TFA. This isn't necessarily bad stuff used for media DRM. It's just a platform lock, which is annoying but hardly the end of the world.
It may be the end of integrated sound for Apple, but I'm not sure that this will be the case.
If they only make you pay once for the beta and for the full version when it is ready, as this one appears to work, that's okay I guess, but this could get way out of hand.
This is how the PragProg guys are doing it. You buy the book up front, then you get major beta milestones. When the book is complete, you get the paper copy along with the most up-to-date PDF.
So far, it's been an awesome model. I've enjoyed comparing the two revisions and seeing the authors' notes. I hope they continue to do this.
There are multiple simple solutions. He could have enabled dmix. He could have installed Fedora Core 4. He could have bought a $10 card that supports the feature he wanted.
dmix doesn't solve the problem, and we all know it. If it was as simple as plug-n-play-ing a program, it'd be done. But it's not. Even the dmix documentation admits that many apps do not take advantage of it yet.
A $10 card that supports sound mixing, but not the other features he wanted. Oh, and a $10 card that you can't just go out and buy at a store. You need to hunt around to get it. Time is worth money.
Quite frankly? Switching to Fedora 4 was the complex solution. Zawinsky has used linux for years. Why should he expect it to stop biting him in the ass over and over?
The only peripherals that ever worked "perfectly" were serial-based laserwriters, even though they were SLOW. Apple's TCP/IP strategy was a joke. Applications were notoriously buggy throughout MacOS 7 and 8 days. And the 68k to PPC transition was NOT smooth, no matter what the hazy memories on Slashdot might say.
Your criticism is based on an experience that is at least 4-5 years in the past. This is 2005. Please join us. We're talking about Mac OS X, preferably 10.3 or 10.4.
So what's left? Freedom. That's the only distinguishing feature left. With Windows or MacOS X you're simply not free. You call that ideology. I call it pragmatism. If you don't know why freedom is important, then that is YOUR LOSS. You obviously haven't been burnt before. When you do figure it out, Linux will be here waiting for you. I promise I won't even say "I told you so".
Switching to Mac OS X hurts this ideological Freedom a lot less than other moves, and certainly a lot less than linux hurts itself by being such a fragmented community. Vast swaths of OSX are open sourced and free as in beer, and the license is OSS-approved. The parts that aren't tend to fall under ESR's definition for what kinds of code shouldn't be open sourced, like the windowing system's video-card-virtual memory-system.
Linux's fragmentation has some benefits, but it hurts them in many areas. For example, why aren't people jumping on Apple's 100% open sourced launchd for their distros? There is no code to port, just distros to reconfigure. It's a much better solution, and it's backwards compatible. Gentoo may have an excuse. But most distros do not. The common excuse for why? A bunch of handwaving about how XML sucks and completely untrue allegations of insoluable Mach dependencies.
How about ALSA adoption? Why would anyone use anything but ALSO and dmix-support these days? Dunno, but people refuse. Apps don't get support, and great features fall by the wayside.
And how about KDE? Dude, Qt is not good for the FSF movement. But people love KDE and it's gaining dominance in the market.
I recommend linux for server applications ever day. It's part of what I do. I believe in linux. But because of non-tecnical reasons, the various distros have a hard time keeping cutting edge and adapting as fast as MacOS X is. Did you ever notice how the biggest advances in the linux user experience tend to occur on distribtuion boundaries?
While freedom is nice, my first loyalty as a geek is to technical superiority and correctness. Call me a sellout, but I'd rather work on The Future, and let the OSS movement continue to play catchup to force commercial vendors to innovate in order to keep charging
Yes, there's still issues with Linux audio. But whining and running off to another OS isn't going to fix them.
Linux Foul! No mentioning Linux Sound. -5 to your advocacy score. Consume!
Dude, ALSA has been "not quite there yet" since like 2001. I left to go to the mac scene myself because I was sick of sound and video issues.This sound thing? It bugs everyone. Everyone everywhere.
At what point do we go, "Gee, this linux sound problem is becoming a major headache?" And why is everyone's response, "Well, then help out!" What kind of lame response is that?
Given the complexity of sound drivers, that's equivalent to, "If you don't like it, leave." And that's what people are doing, you know. Go to a technical conference like OSCON, Rubyconf, Codecon, or heck, even Linuxworld. You see a heck of a lot of luminescent Apples.
Forgive me, but I missed the clause in the Linux social contract where I'm responsible for developing core parts of the desktop system. There are lots of people who could be writing interesting application software, but are hampered by the numerous technical foibles of Linux--or even worse, working on said foibles to the exclusion of good applications.
Okay... I do win the vector calc stuff, obviously. I kind of discard that. When you write good vector code for the altivec, it's monstrously fast.
I get totally hosed on memory bandwidth. I seem to lose by just a few percent on a few others. While my total score is higher, I'm talking about individual benchmarks. I'm just shocked I lose at any of them when Rosetta is involved.
I'm pretty sure that Apple has admitted to the devs at WWDC that Rosetta is in fact a Transative-powered technology.
We all knew that Transative believed they had something big. Evidently they do. The Mach-O binaries with their lazy symbol lookup provide a very nice, natural framework for Rosetta to run.
What I'm wondering is what is broken with the whole directory/folder design? I wasn't aware that there was a problem. And what's the alternative... every file is stored on the hard drive in some arbitrary location, and a query is needed for each and every file access? That seems like a *ton* of overhead to fix a problem that just doesn't exist.
Problems include (but are not limited to):
It's not flexible. We have a shoddy dual-mode hack to get files in more than one place.
It's not flexible. Everyone must look at files exactly the same way, unless they want to do a lot of linking, which is time-consuming.
It's not flexible. Once you organize a group, the only way to re-organize it is to destroy your existing organization.
It's more difficult to secure. It'd be far easier to tag sensitive files as admin files, which the file system refuses to reveal to people without appropriate privledge. Instead of presenting a user with walls (unreadable files and unchdir-able directories), you never reveal dangerous/sensitive info to them.
It makes archival easier.
It makes it easier to think of your data in different organizational frameworks.
Nothing is broken at all. This is just their latest idea to force an upgrade cycle. Filesystems like reiserfs can easily handle millions of files in a directory. I put 100k+ files in a directory in a regular basis and experience no slowdown.
What was "broken" about command line interfaces? Nothing at all? Yet, it's undeniable that for some tasks, graphical user interfaces are superior. And that doesn't just mean the creation of graphics.
So I mean, do you *REALLY* need that? I could care less personaly. I keep my files well organized in my home directory/my documents... seems like a much better solution.
The idea of a DBFS introduces the possibility of more organization, with less work, and with more flexibility.
I can understand your point but it seems as though the "desktop metaphor" goes from "files in folders, folders in drawers, drawers in cabinets" to "my secretary knows where everything is and if she ever decides to leave, I'm screwed."
But s/he can't leave. It's a software agent, and that agent sticks around forever. Also, note that in order to play nice with the outside world that still use folders and files, the system will have to understand them, which means that if you ever jump ship for another OS that is more traditional, you have an export part (albeit a less expressive one).
I don't think there is a significant time savings. I'm almost sure it's a penalty. That doesn't really matter these days. As long as it can serve up something like Slashdot (lots of static file accesses), then it's fast enough.
Slashdot Mirror
Right there, that's 90% of the reason you want to start a new software business, especially with an online service orientation. It's also the best way for the founders to make money in a medium-term timeframe. All the big companies like to buy up tech that they themselves do not possess the agility and drive to develop (yes, this even includes Google, our patron saint of searching).
Just an aside, learn a bit about the business before you spout of a full paragraph of total bullshit.The barriers for entry are not low. Software still requires a significant and non-trivial cost.
But, when I tried it, PyQt had some flaws. It was awkward when you wanted to make new widgets, in particular. And, maybe this is fixed, but I had a heck of a time reusing some components that my coworkers wrote.
Python is a great language with a lot of potential, but I couldn't help but feel that Qt isn't very Python-ish, and it showed in the experience. I'll check into it again.
Unless they used SWIG and MOC to do the binding.
An SB Live is whatever they want to call an SB Live. As long as it provides the same capabilities, it's still the same product. It still "works like" an SB Live. It's just cheaper to produce now, and needed a new driver mapping.
I have 0 sympathy here. Driver writers have to deal with far less change over time than software developers. Their initial job may be harder, but many drivers just don't change, or only change insignificantly.
But I don't think the problem is manpower. I think there are a ton of smart people who have great ideas. The linux community is just slow to adopt them. Why is ALSA still pissing off Jamie Zawinsky? Because people aren't using all its cool features. It's not a technically inferior solution.
If you want to get bug reports, make it easy to report bugs. Set up a gmail account, hook it up to your RSS reader, and when your program crashes, detect this and offer a small form to fill out.Or, have an active community of users, like what ESR details in his book.
This is true, if you don't have a vested interest in your software being used by anyways. If all you want to do is dump an unusable loaf of crap into a trash bin on the internet, feel free to make yet another sourceforge project that lies unrealized or unusable. Criticism can be hard to swallow, but as a software developer, it really pays to listen to it. If someone says, "This bug sucks!" then don't respond with, "Did you report it?" Respond with, "Consider it reported."When MS was entered into the anti-trust suit, this was not the case. We're all talking about that legacy.
However, I might note that if you remove IE, many legacy apps do break, because they try and launch IE explicitly (and erroneously, but that's not the point).
Obviously, they can do it now. XP N is proof that it is no longer that way. But the impression is still there. Honestly, I have no idea why the EU ordered things they way they did. To me the ruling didn't seem to help much of anything, and seems very dated.
I don't think anyone here at /. is saying they shouldn't be allowed to bundle libraries. Libraries are good.
I think even uninstalling is a red herring. What pisses many people off about IE is that it seems utterly unavoidable in common use. Not only because it's an application that the system depends upon, but because it's so visible to the users.
When you run on OS X, Apple has WebCore and WebKit. They're part of the OS. Remove them and watch other apps break like dry twigs. But you can drag Safari to the trash just fine, and nothing will break. While this may be only a token gesture when 90% of your application is just a shell for the libraries, it's an important one. It's this feel that, carefully cultivated, helped MS utterly destroy Netscape back during the browser war.
The Windows Media Player is in a similar situation. The tools that other apps depend upon should be tied to quietly lurking libraries, not Microsoft applications. Imagine if DirectX was tied to a specific application, like a Microsoft 3d Modelling Program. Even dependant app becomes a form of indirect reinforcement and even advertising for the MS core apps.
But, I am baffled why TrollTech stopped at signals and slots instead of allowing real smalltalk style dynamic message sends. If you're going to introduce code generation to a framework, you need to get as much bang with the least amount of intrusion as possible.
They could have removed these awkward signals and slots, and instead introduced an Objective-C style delegation paradigm. Since they're parsing the header, why not say, "All virtual functions are now dynamically dispatchable with some simple syntax?" This pattern has been proven to work exceptionally well in staticly-typed environments. They could have even improved upon that model by allowing for multiple delegates.
I appreciate Qt as a cross-platform environment. But when I compare it to specific environments like Apple's Cocoa (or GNUStep, which is similar), or even Swing, I find that it's lacking. I understand there is a language handicap here, but that doesn't change my opinion.
Keep in mind that moment magnitude is just a convenient way to talk about seismic moment the way we would talk about the classic Richter scale magnitude.
So it's dimensionless, if I recall correctly (and wikipedia confirms this).
I suggest you read the wikipedia articles for more information. I am way out of my depth talking about geology. I only remember a few tidbits of facts from an introductory college class.
I know backwards compatability is a good thing, but at some point we need to get off the bus and say, "Standard is standard. If you break on this code, it's your problem."
It's not like we haven't had years to update these sorts of things. With TR1 incorporating some Boost features into the standard, and TR1 being the future of C++ in many eyes, it's time to stop coddling.
Since Qt is primarily a Linux, MacOSX and Windows phenomenon, I seriously doubt that TrollTech would lose sales from such a move.
This is what I wanted to know, thank you.
I agree with you, I wish they would find a better way. Or, they could at least be honest and admit they're crafting a new C++ compatible language.
But setting it up? A pain. Now, if you don't unit test your code, you can get away with qmake, no problem. But if you want to have a nice make test/check target, you're SOL, and have to go to either rolling your own or using a Qt-aware build tool, such as automake with Qt macros added in. Or, of course, you can use a controlling makefile. But this solution isn't entirely cross platform and can be confusing to people new on a project.
I find the lack of a flexiblity in their make tool particularly annoying. I've read every bit of documentation Qt3.3 has on the subject, I've asked other developers and put forth questions on mailing lists. No one seems to even think about qmake and unit tests. If they removed the need to moc source files, they'd open up the build process to more tools and make it easier to integrate into an existing project.
While that approach may be a bit more complex for the library maintainers, it certainly would make life easier for the developers, at least in my opinion.
Despite being a Qt3.3 developer, I've had almost no chance to check out any of the buzz on Qt4. What I want to know is, are they going to find a more elegant and in-language way to handle signals and slots, preferably one that does not require the use of an extra compile phase?
I'm all for meta-language programming. I love it. But not at the expense of an extra compile phase which complicates my makefiles and can introduce errors that were introduced when the generated code was inserted. I'm happy that Qt4 will finish opening up as a GPL'd library (that removes one of my biggest complaints about Qt), but are my technical concerns also going to be invalidated?
To me, this extra phase and the awkwardness of signals and slots syntax is a real weakness when compared to frameworks like Cocoa that don't need to resort to it. Now, I understand dynamic dispatch is hard in C++, but if the Boost people can get HOF-aware template-based lambdas, I'm certain that TrollTech could do better.
Not to offend anyone, because even most news agencies get this wrong, but the Richter scale was long ago deprecated for use in large quakes. You can check out the information on the Richter scale at Wikipedia, but the gist of it is that the Richter scale didn't really relate to the physical characteristics of the quake in an identifiable way.
The new system that geologists use is Moment Magnitude, which is more physically identifiable. However, it'll have values fairly similar old familiar Richter. The real benefit is that it doesn't have a cutoff limit, beyond which all earthquakes simply fall to the same value.
Just to give people a feel for the intensity of the quake, every step on the moment magnitude scale is an increase in energy by a factor of 10^1.5. Consider that a 7.0's factor is then x10^10.5, which is a pretty damn huge amount of energy, about 31622776602 times more than a magnitude 1 quake.
What I think the GP was getting at is that the inital cost of ANY system is usually quite small compared to the development and maintenance costs over time. In that regard, Linux is not free. You still pay people to take care of it. For home users, you pay with your time to take care of it. Now, certainly, Linux is a lot easier to handle than it was years ago, but it still has some fundamental issues.
I'm not saying that Linux has a higher TCO, but I am saying that Linux's TCO is nonzero, and it's not immediately obvious that it's lower than MacOSX.
Hope this helps.
So far, it's been an awesome model. I've enjoyed comparing the two revisions and seeing the authors' notes. I hope they continue to do this.
- dmix doesn't solve the problem, and we all know it. If it was as simple as plug-n-play-ing a program, it'd be done. But it's not. Even the dmix documentation admits that many apps do not take advantage of it yet.
- A $10 card that supports sound mixing, but not the other features he wanted. Oh, and a $10 card that you can't just go out and buy at a store. You need to hunt around to get it. Time is worth money.
- Quite frankly? Switching to Fedora 4 was the complex solution. Zawinsky has used linux for years. Why should he expect it to stop biting him in the ass over and over?
Your criticism is based on an experience that is at least 4-5 years in the past. This is 2005. Please join us. We're talking about Mac OS X, preferably 10.3 or 10.4. Switching to Mac OS X hurts this ideological Freedom a lot less than other moves, and certainly a lot less than linux hurts itself by being such a fragmented community. Vast swaths of OSX are open sourced and free as in beer, and the license is OSS-approved. The parts that aren't tend to fall under ESR's definition for what kinds of code shouldn't be open sourced, like the windowing system's video-card-virtual memory-system.Linux's fragmentation has some benefits, but it hurts them in many areas. For example, why aren't people jumping on Apple's 100% open sourced launchd for their distros? There is no code to port, just distros to reconfigure. It's a much better solution, and it's backwards compatible. Gentoo may have an excuse. But most distros do not. The common excuse for why? A bunch of handwaving about how XML sucks and completely untrue allegations of insoluable Mach dependencies.
How about ALSA adoption? Why would anyone use anything but ALSO and dmix-support these days? Dunno, but people refuse. Apps don't get support, and great features fall by the wayside.
And how about KDE? Dude, Qt is not good for the FSF movement. But people love KDE and it's gaining dominance in the market.
I recommend linux for server applications ever day. It's part of what I do. I believe in linux. But because of non-tecnical reasons, the various distros have a hard time keeping cutting edge and adapting as fast as MacOS X is. Did you ever notice how the biggest advances in the linux user experience tend to occur on distribtuion boundaries?
While freedom is nice, my first loyalty as a geek is to technical superiority and correctness. Call me a sellout, but I'd rather work on The Future, and let the OSS movement continue to play catchup to force commercial vendors to innovate in order to keep charging
Yes. Heaven forbid that Creative use new, cheaper chipsets in their cards to lower the prices!
Damn these hardware vendors for releasing new models over time!
Dude, ALSA has been "not quite there yet" since like 2001. I left to go to the mac scene myself because I was sick of sound and video issues.This sound thing? It bugs everyone. Everyone everywhere.
At what point do we go, "Gee, this linux sound problem is becoming a major headache?" And why is everyone's response, "Well, then help out!" What kind of lame response is that?
Given the complexity of sound drivers, that's equivalent to, "If you don't like it, leave." And that's what people are doing, you know. Go to a technical conference like OSCON, Rubyconf, Codecon, or heck, even Linuxworld. You see a heck of a lot of luminescent Apples.
Forgive me, but I missed the clause in the Linux social contract where I'm responsible for developing core parts of the desktop system. There are lots of people who could be writing interesting application software, but are hampered by the numerous technical foibles of Linux--or even worse, working on said foibles to the exclusion of good applications.
Okay... I do win the vector calc stuff, obviously. I kind of discard that. When you write good vector code for the altivec, it's monstrously fast.
I get totally hosed on memory bandwidth. I seem to lose by just a few percent on a few others. While my total score is higher, I'm talking about individual benchmarks. I'm just shocked I lose at any of them when Rosetta is involved.
I'm pretty sure that Apple has admitted to the devs at WWDC that Rosetta is in fact a Transative-powered technology.
We all knew that Transative believed they had something big. Evidently they do. The Mach-O binaries with their lazy symbol lookup provide a very nice, natural framework for Rosetta to run.
That the P4 3.6Ghz Rosetta benchmarks outspec my Dual 800 G4.
:)
I have never felt so inadequate in my life. I know my machine is nearly 4 years old, but to get owned by a machine doing binary translation? Ouch.
- It's not flexible. We have a shoddy dual-mode hack to get files in more than one place.
- It's not flexible. Everyone must look at files exactly the same way, unless they want to do a lot of linking, which is time-consuming.
- It's not flexible. Once you organize a group, the only way to re-organize it is to destroy your existing organization.
- It's more difficult to secure. It'd be far easier to tag sensitive files as admin files, which the file system refuses to reveal to people without appropriate privledge. Instead of presenting a user with walls (unreadable files and unchdir-able directories), you never reveal dangerous/sensitive info to them.
- It makes archival easier.
- It makes it easier to think of your data in different organizational frameworks.
What was "broken" about command line interfaces? Nothing at all? Yet, it's undeniable that for some tasks, graphical user interfaces are superior. And that doesn't just mean the creation of graphics. The idea of a DBFS introduces the possibility of more organization, with less work, and with more flexibility.I don't think there is a significant time savings. I'm almost sure it's a penalty. That doesn't really matter these days. As long as it can serve up something like Slashdot (lots of static file accesses), then it's fast enough.