The open source community at large needs to take off the tinfoil hats and start doing some real development on these platforms.
This is simply not possible. DRM is fundamentally about shared -- but hidden -- encryption keys. DRM software cannot be Open Source because then you'd be able to see the keys or extract them from the datastream. The only way for DRM to "work" is to have a complete chain of hardware and software for which users have no control over. For example: hardware which will only operate and exchange DRM keys with cryptographically signed software. That software cannot be Open Source and it cannot run on an Open Source operating system kernel. (otherwise, you could just probe memory and find the secret key) There is no middle ground here. It's physically impossible to implement DRM in Open Source software.
Having that said, some technologies, such as TCPA, are indeed dual purpose. Let me give you an example. If the user -- rather than the hw/sw vendor -- controls the encryption keys, he/she can password protect his/her data or cause the hardware to run only binaries that he/she has signed. This is not DRM; it's just a form of hardware-based data security. Of course, TCPA can also be used for evil -- when vendors have their own keys hardwired into the chips and the user cannot access them. This use of TCPA allows for all the bad stuff: hardware that will only run a certain vendor's OS, media that will only play on certain "trusted" hardware and software, etc.
I sort of see rails as occupying a middle ground between PHP and a java app server. You get the structure of a java framework with the ability to know stuff out of PHP.
That's a surprisingly accurate assessment for supposedly being "uninformed" about the topic. I have PHP and Java background and have recently researched Ruby a bit. At this point, Ruby would now be my choice over PHP for all but the lightest-weight jobs. If Ruby improves in the area of templating and component-based UI frameworks, it could knock PHP down quite low on the list and start to compete in the low-end Java arena.
Java app servers, on the other hand, still run in an arena that the scripting languages can't begin to touch and by architectural nature never will. What is a more interesting comparison is modern lightweight Java tools (like Spring/Hibernate) vs. Ruby. These Java tools have a ways to go regarding loosing additional XML baggage, but they are still a significant improvement over current heavyweight J2EE app servers. What is most interesting is the convergence. Java tools are rising to the challenge of becoming simpler. Even the EJB 3.0 and J2EE 5 specs are heavily geared towards this goal. The question becomes: If Java tools get closer to the simplicity of scripting languages without losing the power of their architecture, where is the incentive to use scripting languages? Conversely, the scripting languages have simplicity nearly mastered but they have no headroom architecturally.
Yeah that otherwise being that new game, or dvd copying app, or accounting package they bought from the store not installing...
You're missing the point. People will use whatever comes pre-installed on their computer. Companies will be forced to write for Linux as a result. Now, the reason why Linux will come pre-installed should be clarified. Businesses are the first market for Linux and are where all the change will originate. The home desktop will change as a byproduct. Home users will want the same thing they use at work. Incidentally, this is why anyone who knows what they're doing is targetting the business market with Linux, not home desktops, at this point.
Sorry to bring this up over and over.. but an installer for 3rd party commercial apps that will work on at *LEAST* half of the installations/distros out there, and in future versions is what is needed for *ANY* hope of a widespread linux desktop...
You're assuming that not all of the software that consumers need will come packaged *BY* the distribution. You're also assuming that consumers will use a plethora of Linux distros instead of one or two popular ones. (Most distros are not aimed at home consumers, and it won't matter if they're not "supported" by games, etc.) Third, you're making the assumption that proprietary* software will still be popular by the time Linux/OSS has taken over in the business world and started transforming the home market.
* You used the word "commercial" when you really meant proprietary. Much of the best F/OSS is commercial but that doesn't make it proprietary. Before you start going on about how nobody will make money on open source games, consider that the real value in video games today is found in online services and associated graphics, storyline, levels, and multi-media content.
IMHO OSX brings enough unix for those that want it.
If you think people were previously going for Linux only because it's "unix-like" you're entirely missing the point.
Windows is king because you can install a piece of software written for windows 95 (ten years old) on windows XP.. generally without issue.. that can't be said for Linux.
Almost nobody actually does this, so the point is irrelevant. Home users don't run Windows because they need to run old software (heck, most can't even find all the disks that came with their latest computer). No, they run Windows because it came pre-installed. Then they find additional software to run on it.
OSX is largely the same for the past 5 years... the simple fact is linux is a great server platform, it downright sucks as even an option for mass consumption
Face it: OSX is not a replacement for Linux on the desktop and it never will be unless Apple makes it 100% F/OSS. OSX is a niche product that runs only on expensive Apple hardware. Linux has a far greater chance of taking over the desktop market than OSX at this point -- not because it's currently as polished but because it's not tied to a single vendor. But to be fair, I don't think Apple wants to create a mainstream, Windows-killer product with OSX. They've always been satisfied to provide a decent product to a smaller, loyal customer base.
If everything could ultimately be tracked back to you eventually, things like spamming, virus distribution, defamation, on-line fraud, and numerous other harmful behaviours would be dramatically reduced.
Identiy systems are the wrong solution to legitimate problems.. Spam and viruses are technology problems and thus can be fixed by technology. (My spam filter eliminates about 99.5% of junk and I don't deal with viruses on Linux or OSX machines) Defamation can already be handled through the same legal means as offline and really is not that big of a problem anyhow. (anonymous sources online aren't exactly considered trustworthy to begin with.) The vast majority of online fraud could be eliminated if all credit cards simply had rotating pins or any other secondary verification scheme. (like "Verified by Visa") I don't know what the "numerous other" harmful activities you refer to are, but I can't think of anything that could be suitably prevented using identity systems.
Frankly I don't want a universal "tracking cookie" that I can't turn off. The ramifications would be far worse than any problems partially alleviated. In fact, it would probably spawn new types of criminal activity. IP addresses are not anonymous to governments, but they are reasonably anonymous to illigit marketers, identity thieves, stalkers, etc.
I think you may be a bit out of touch with the "average user". If a Linux system "just worked" then yeah, maybe they'd choose it over OS X or Windows. But Linux is never going to "just work" that way.
I think you are a bit out of touch with the fact that nearly all users simply use what is provided to them -- whether by Dell/HP/etc., Apple, or their employer. The notion that Linux must be perfectly easy to install so that people can convert their old machines is somewhat nonsense. Most consumers just throw out their computer and buy a new one. If that new computer has Linux instead of Windows, they'll use it. (and half will think it's a new version of "Microsoft" until someone informs them otherwise..) On the other hand, I wouldn't put it past Linux to start catching on as a way to re-use old consumer PCs where Windows has been destroyed by Spyware or its own doing. If you're formatting the drive anyhow and don't care about old data, most modern desktop-centric distros will provide a useable working environment with minimal knowledge and will detect all major hardware.
The mere existence of multiple windowing systems means that applications will be targeted at one of them. Sure, if the average user decides he likes Gnome best, he can still use KDE applications, but the little inconsitencies in the interface will start to wear on him.
First of all, the consistency is no worse than Windows software, where almost every program today has its own custom widget set and/or bitmap themeable GUI. Office 2003 is not even consistent with the Windows XP interface -- nor is Windows Media Player, nor iTunes, nor AIM. This is not a major issue to most people. They're used to it. Sure, it's an eye sore to those with asthetic taste, but it's not a show stopper. I would go as far as to say Linux GUIs are more consistent for the most popular software.
The cut and paste issue is likewise a non-issue today. Go try it yourself. Cut from KWrite and then paste via Ctrl-V into gaim, gedit, OpenOffice, Firefox, and KWord. No problems whatsoever. This argument is bunk. It was valid 5 years ago, but not today.
Linux still needs a lot of work to be that thing.
I often say the same thing for Windows and Mac OSX, though OSX may have a slight lead at the moment. The whole consistency and usability issue is going to keep getting better thanks to work by the freedesktop.org group.
That's all nice, execpt that for same dozens of options in RoR you don't need any XML.
They aren't the same dozens of options. ActiveRecord is catching up, but it's not a feature equivalent to Hibernate yet.
Of course, many real-world business apps require far more than just a CGI-based front controller and an O/R backend store. After further study, RoR indeed looks like a great tool for developing a certain breed of web apps -- the typical e-commerce, blog, cms, etc. variety. I would use it in place of PHP any day for this sort of app because it really does everything right. However, these examples are lightweight web apps which can be made almost entirely stateless and which do not have complex transactional, auditing, scheduling, and security requirements. Most business apps do have these sorts of requirements and often their use cases dictate a significant amount of application state. RoR is not up to this task by its very nature as a CGI scripting language. It is request driven and all state disappears upon completion of the request unless it has been persisted to the (comparatively slow) database backend. Scheduling is likewise impossible.
It's funny to observe mazochists fighting for their passion:)
It's funny to observe scripting language developers claiming their language of choice is the right tool for every job.
Your faulty illustration demonstrates precisely where the article's comparison goes terribly wrong. Those 38 lines of XML required by Hibernate give you the ability to specify dozens of options and features that ActiveRecords doesn't have. And those options are actually required when you're not just writing a toy application or tech demo.
Of course, it should be mentioned that most likely the Java IDE you are using will automatically generate that Hibernate XML for you. You can hand tweak it later, but the hard work is already done.
it's very likely that they're going to grow at a fast rate and add a lot more music to their portfolio.
Not likely. They have near-zero mindshare and their artists are entirely unknown. What is going draw people, especially pop-culture-inundated students, to this tiny new catalog? Absolutely nothing at the moment.
The problem with all current attempts at promoting independent media is that everyone assumes they can use the same methods as the big guys -- like actually selling music, whether on CD or via download. They're thinking way too much inside the box. You would think that after thousands of failures, independent artists would have realized that they've continually put themselves into an obvious catch-22.. Most people only buy music if it is popular. Music cannot become popular without being heard. If you sell your music, only people who buy will hear it. If you're not popular, nobody will buy your music. The major labels break out of this catch-22 via marketing and controlling influence over all popular broadcast media. In other words, they force music to become popular so that artists can make money. Now, once an artist is popular, they no longer need big labels, but by that time they've been contractually entangled and it's too late. Independent media has almost no marketing and almost no influence over popular broadcast media. The only way for a new independent artist to become popular in the mainstream is to give away their music in an effective manner. After they are popular, they can make money however they choose -- by selling albums, concert tickets, merchandise, etc. Of course, most new artists think, "If I give away my music, I can't make money." But the opposite is true. If they try to sell their music at the beginning, they will NEVER make money or else it'll take them decades to become marginally popular.
But how does one give unknown music away effectively? Many have tried before but never with much success. Why? Because they've all done so passively. Simply putting up a website or putting songs on a P2P network will not effectively give away music if it is not already popular. These are good tools once momentum starts to build, but they don't solve the problem. The catch-22 simply becomes: People will not download your music if it isn't already popular. Sure, the handful of people who care about independent music might stumble upon it, but there aren't enough of these people to meaningfully support artists. The only way to attain popularity with unknown music is to actively promote it. The method depends on the audience and environment, but it always involves investment of time and money. This is no different than starting a personal business. There are always upfront costs and sometimes even a small loan is necessary. But where there is no risk, there is no reward. It would seem that most independent artists today are terrified of risk.
Never underestimate the marketing power of backpacks filled with $0.10 mass-produced CD's labeled "feel free to copy for all your friends."
I love java and hibernate and all of the powerful ideas it introduces and brings to the table, but RoR just makes things so easy and fast. I don't know how easy it would be to write something huge in it..
RoR makes easy things easy, but Java makes hard things possible. (You could also insert Python, Perl, or PHP in place of RoR and that statement would be equally true.) The "alternatives" to Java are all missing an O/R tool as powerful as Hibernate, an AOP/IoC framework as powerful as Spring or AspectJ (if they have one at all), and a UI framework as powerful as Tapestry or JSF. The IBM article in the parent post is pretty terrible because it compares Java vs. RoR for ultra simple web applications which could be feasibly implemented in ANY language. It wouldn't surprise me if RoR is an excellent alternative to PHP, but it's nowhere near an alternative to Java for that which Java does well.
I don't see any room for.net anymore. Unless you like writing non-MVC apps:)
Largely through copying of what has worked with Java and friends,.NET has become a very strong competitor to Java for mid/large scale applications...So beware of becoming too smug. And there's nothing saying that.NET apps are non-MVC. The next several years are going to have developers on each side working hard to surpass what the other is doing. If Ruby wants to compete with the big dogs, it's going to have to grow up really quickly and get some real tools in its belt. Right now, Ruby is not something you would use to write a large, complex enterprise app. At this point, the Open Source community would be far better off rallying behind Java (aka. a Free "java") than any scripting language or immature newcomer like RoR. Java needs to be improved, but it already does an enormous amount right.
Gnome too configurable? You must be talking about Gnome 1.0... not anymore.
Ironically, GNOME is no less "bloated" than KDE in terms of memory usage in a typical desktop session. In my experience, KDE is simply more efficient. Both environments require a relatively modern machine to perform well, but KDE gives you far more features and configurability in the process.
If you're asking me, it's because KDE is less driven by politics and more by what users want.
Of course, the problem is most prevalent in Java software, which the KDE developers thankfully seem to be avoiding. (I remember a remark someone made about Eclipse... 512MB RAM = slow, 1GB RAM = fast... which is ASSINIE for a text editor).
Eclipse is not a text editor. It's an extremely powerful extensible IDE and as such it is quite efficient and useful. Eclipse saves developers an incredible amount of time and that time is worth a few orders of magnitude more than the cost of the extra RAM it uses over a lightweight IDE. Given the cost of a comparable commercial IDE, the RAM cost is absolutely laughable. Incidentally, the number you quoted is quite exaggerated as Eclipse runs perfectly fine on a 512MB machine for most purposes. Of course *any* serious development machine should have 1GB+ anyhow given how cheap memory is today. If your company can't afford $50 to make you vastly more productive, you'd better start looking for a new job quick!
As for Java in general, KDE developers are not "avoiding" it. It's just not the right tool for developing lightweight DE software. Java is neither slow nor bloated when used in the context for which it was designed. The mythical Java bloat is simply the memory overhead of the JVM. You'll have that in any managed code environment so get used to it because it's the way of the future for many types of apps -- whether Java or.NET/Mono or whatever. With a large application, that VM overhead shrinks rapidly and becomes negligible. And of course, VM's provide very nice security features as well.. again something well worth their overhead memory cost.
I run Java both at work and at home, on decent machines, and I find the performance to be excellent (certainly faster than.NET on either machine). I've grown to love the so called "bloat" - that is, it seems that any time I think to myself "I wonder if Java will let me do Y without reinventing the wheel" I find out that I'm not the first to have thought of it; it's actually implemented! (..same analogy applies to Java as KDE!)
No, it is as evil as it seems. It will hopefully fail as a result and leave a void to be filled by DRM-free open source software. But it's still evil in and of itself and there will likely be many casualties in the ensuing battle against freedom and innovation.
"..But this will be good for linux and open source in the end."
The only way that Open Source is ever going to take over the media content scene is if artists and movie producers start going independent en masse. Linux is already largely "cut out of the content market" in the US because of 1.) bogus patents related to popular (though not necessarily superior) video and sound compression formats and 2.) DRM schemes which are trivially circumvented but for which tools to do so are now illegal to distribute in popular Linux distros. For all practical purposes, Linux already can't play popular media files in the US. Granted, this doesn't stop the experts, but it does stop the casual user and is therefore a major impediment to Linux on the desktop.
It's this simple folks: The only answer is independent media. Hollywood will push DRM till the day they become irrelevant and people will buy it up because they won't know any better. But it's going to take quality alternatives.. not fan films.. not crappy garage/bar bands. Napster, MP3.com, and friends ultimately failed because they never lived up to their promise -- to actually provide an alternative distribution medium for quality content. All they would have needed to do is foster one quality band into the popular music scene and hundreds more would have followed. The RIAA would have been history almost overnight as bands suddenly realized they no longer needed to "get signed" by a big label to rise into popularity. But instead everyone was enamoured with free beer instead of free speech and P2P turned into a giant stupid warez scene. There's still hope, but time is running out.
I can see Apple gaining a wider audience on the other hand. They're moving TOWARDS open source, not away from it.
Apple is using Open Source only where it benefits them directly. It's better than nothing, but they're hardly "team players" in the Open Source community. MacOS X is very much designed with platform lock-in in mind. Simply ask yourself this: Why is Cocoa not Open Source and not cross-platform? Apple also had a chance to jump on board the Linux train but they instead chose to do their own thing and not play along.
Public key encryption is used to ensure only the key holder can access it. I can copy the encrypted file to whatever device I like that can read and act on my key. Without my key, it won't work.
You don't seem to understand how public key encryption works. In your scheme, devices can only decrypt the files if they have YOUR private key. But if you hold and control the private key, it's no longer DRM because that private key gives you access to the non-encrypted data and you can do whatever you want with it at that point. DRM is always, without exception, based upon a shared secret. Somewhere, whether it's in software or hardware, there's a master decoding key hidden. DRM is by nature incompatible with Open Source because of this. Always has been, always will be. Either you have control over your own hardware/software or you don't. There's no middle ground.
Say we disbanded copyright for software tomorrow, but continued to permit liability disclaimers - then where would GPL be? That's right - it'd be just another BSD license. People who add GPL to useful code prop up the existing copyright structure..
The only reason why GPL exists is because it is necessary as a weapon against copyright abuse. So you're correct with the statement that without software copyright we'd wouldn't need GPL. But the situation isn't going to change anytime soon. If it does change someday, great.. we won't need GPL anymore. Until then, GPL preserves freedom better than BSD and provides a temporary solution while copyright is being modernized.
I like the idea of keeping my code private, via the BSD license.
GPL doesn't say you can't keep your code private. This is a common misconception. And if you're not sharing the code of the software you distribute, you're not going to be using GPL *or* BSD.
By what process can the mess made by the USPTO regarding software patents be corrected, while still rewarding those few innovators whose genuine software patents can be acknowledged?
Anything deemed a "genuine" software patent is completely unusable to OSS for 14 years. Given that the ideal future is one where all software is Open Source, do you really want to go there? There's no "good" solution to software patents. They're all bad. They all hurt innovation. They're all incompatible with Open Source development. Software, like science and literature, is an evolutionary field where knowledge arises as a natural progression. In it, there is no such thing as a truly novel idea.
Which doesn't sound like doing it for the greater good which open source software is many times made out to be.
The ultimate "greater good" in Open Source is that all software eventually becomes Open Source because that is what is best for technological progress and for the good of society. BSD-license-using folks can't see past the current state of affairs in the software industry and thus assume that we actually need proprietary software to begin with.
The reality is that Open Source movement has simply not yet reached the tipping point. Today, there is still incentive for companies to stay proprietary, but this will not always be the case. At some point it will actually be easier / more economically beneficial to go Open Source in every case. We will witness the final death of the software vendor and rise of the service provider. Life will go on. The software industry will continue to grow. It'll just be on different (more efficient, more fair) terms. And fortunately for developers everywhere, it's pretty near impossible to monopolize a services industry with minimal barrier to entry.
I am particularly fond of it for libraries, frameworks, APIs, etc.
I definitely agree. LGPL for libraries/APIs helps to strengthen the foundations of all our code. I would much rather see a proprietary developer use a LGPL library than a proprietary library. Why? Because there's a pretty good chance they will end up helping to improve and/or debug it in the process. If someday that proprietary developer decides to open up their code, it will immediately work with our Open Source libraries. Granted, I'd rather not see proprietary developers at all, but hey.. embrace and extend right?
Of course, I'm 100% for GPL for end-user software. Otherwise you're just giving away the farm and inviting freeloaders. If somebody really wants to go proprietary, they can dual-license your code and support your future efforts.
That out of the way, capitalism is about capitalizing labour; that is, putting people together that create more value than if they worked seperately.
Implemented properly, Open Source is fundamentally about transforming the software industry into a pure capitalist labor market which is free of most artificial barriers and regulations. The key is really how to pool resources so that those who need software can pay for its initial development. (the capitalist value is in this initial development labor, not the final product which is freely shared and replicated at no cost)
At first, it sounds like a free-rider problem waiting to happen, except the reality is that:
1.) The largest percentage of software produced today already involves either contracted or in-house development.
2.) In a highly competitive market, a cheaper solution that gets the job done is usually the best option. Even if ones competitors can partially free-ride on it later, they're already far enough behind that it doesn't matter. Either way there's always the cost of implementation, customization, and internal support -- these don't go away just because something is Open Sourced. (If you're really smart, you can spin off a new division and make money supporting the software you wrote or enhanced in-house!)
3.) Paying for Open Source development doesn't necessarily mean starting a new project from scratch. It could be development of one needed feature in an existing project that is otherwise satisfactory.
..it will be in the interest of those who wanna make a sh** load of money to patent software based on the source, not a description of what the thing does.
Hm.. I'm not quite sure what you're getting at here. Copyright is adequate for protecting a particular implementation whether the source code is open or not. Patents have no logical place whatsoever in software.
And it doesn't take a MS guru to setup a secure "full-featured mail or file/domain server" using Windows?
It takes experience, but not necessarily a high level of specialized expertise. You can grab any of hundreds of books available on Windows Server admin and be up and running in a day at most. You really can't say that for a Linux server purposed for Samba or mail and running a stock free distro like Debian or Fedora. Assuming no prior knowledge of the software (only general Unix admin skills) it can easily take a solid week to figure out how to properly install and integrate say.. Postfix + Cyrus + OpenLDAP + Amavis + Spamassassin + OpenXChange as a real working solution comparable to Exchange2003 for a corporate office. If you're a Windows admin on staff at some company, are you going to spend that much time on a project not guaranteed to work due to your non-Unix-guru status? Probably not.. even if you toy around with Linux at home for kicks or to stay up on the latest. This is what I'm getting at. Today's Windows admins need to be the target audience of OSS. We HAVE to meet people where they're at or it's a no-go. Regarding security, you shouldn't have to be a guru on ANY platform to achieve security. If you do, it's a design failure. Both Windows and *nix currently fail in this category. That's why there's a growing market for security consultants.. companies don't necessarily trust their own admin staff to be perfect!
Commercial software and FOSS both have their places.
FOSS can and should be commercial software. It just isn't proprietary. (I'm increasingly trying to get people to use this terminology instead of the inaccurate commercial == proprietary)
Firebird , which is based on Borland's Interbase. Though I've only recently installed it I hope to learn it soon.
True.. I haven't had time to look at it much but should have made mention. I don't know offhand how it compares to PostgresQL, though I've little doubt it is ahead of MySQL in most areas.:) Good luck learning it.
It already happened. The meteor is the GPL. You cannot do business as usual (if you are a rapacious beast, that is, intent on devouring all in your path) with the GPL. Microsoft has come to an almost dead halt in its efforts to fight Free and Open Source Software. Everything they have tried has failed, to a greater or lesser degree.
Open Source has made important inroads but lets not get carried away and start the celebrations right in the middle of the battle. It's all quite far from over and MS has plenty more tricks up its sleave with Longhorn, Office 12, and.NET. Fact is, OSS has made virtually no impact on the desktop or small/medium business server so far. This isn't going to change unless there's some fundamental rethinking of the whole OSS process. How so?
1.) Every significant end-user software project MUST be commercialized. The current rate of progress is insufficient to keep up with the proprietary giants, let alone have time left over for significant innovation. Volunteer / hobby labor is not sufficient. Major projects like OpenOffice, KOffice, Gimp, Gaim, Inkscape, Scribus, Mozilla, etc. which all aim to meet "mainstream" needs in turn need full-time, paid developers. Some already have them through corporate sponsors, but they need more.
2.) OSS developers need to focus on real solutions and not just raw materials that somebody else might find a use for. This is one of the prime reasons why existing OSS solutions are passed over.. they're far too costly to implement for smaller organizations. As example, it shouldn't require a Unix guru to set up a full-featured mail or file/domain server -- but it currently does. (Or you can spend nearly as much as the MS solution by going with a proprietary Linux distro to integrate the raw materials for you.. but then where's the benefit?)
3.) Many OSS developers need to quit wasting time with low-end technology like PHP and MySQL and move on to Java and PostgresQL. As a former PHP4/5 developer, now Java developer, I can honestly say that I'll never go back. PHP/MySQL definitely has its place for simple web tasks (as it was originally designed in its early days) but too many people believe PHP is something it's not and architecturally can never be. Open Source Java tools completely blow away everything that exists for PHP when it comes to doing real business application development. (incidentally, business apps are a major weak spot in the OSS landscape) It is unfortunate that people like ESR have poisoned the OSS world with lies about how Java should be avoided at all cost regardless of the fact that it is often the best tool for the job. Other than the trademarked name, Java is no more proprietary than C/C++. It's a language.. a tool. If the only good Java implementations are proprietary ones from IBM and Sun that's the OSS community's fault for not meeting the need as with other languages in the GCC suite. Lets put it another way: Java is the only real competitor to.NET at this point and even then it's a close race. The OSS community needs to fully embrace and support Java.
Solve these three problems and we'll see the true revolution happen. Ignore them and OSS will be destined to forever satisfy a niche market.
I don't know about anyone else, but my biggest gripe with X performance these days is the rendering speed of RGB subpixel anti-aliasing. (at least on Radeon cards, which is all I have..) It's not unusably slow, but it's highly noticable and makes everything feel sluggish.. especially scrolling.
Curious? Do a quick test: x11perf -aa10text x11perf -rgb10text
On my system, running X.org 6.8.1, regular AA text is about 8x faster than RGB-AA. RGB-AA produces no slow-down in Windows on machines I've checked, so it must be a driver or implementation issue.
Windows has SUS, whereas Linux doesn't seem (excuse me if I'm wrong) to have any kind of distributed patch management for large businesses.
Windows has one distributed patch management system. With Linux/BSD/etc. there are multiple approaches depending on what works best for your organization. Every Linux distro I've used is quite flexible in this regard. In my opinion, the ultimate is diskless workstations running off a fast file server (SCSI RAID, 1000Bt network). (30-40 workstations per server, replicate servers as needed) You can use local hard disks for caching if you like, but the ease of administration is the same.
Advantages: - workstations are stateless and can be swapped out on the fly with no syncing - reduced heat, power usage, and noise from workstations - no need to either leave machines on at night for automated updates or initiate updates upon startup - guarantee that everyone is using the exact same software
Updates are pretty much as simple as running a package manager on the master shared filesystem root used by the diskless machines:
Do you also look forward to not having the option of "owning" any of the software you have on your machine?
Who says you won't be the one running the server? Desktop-centric computing is beginning to die out with the evolution of the web and embedded devices. But that doesn't mean you'll have to pay for ASP's instead. Stick a fast Linux server in your basement and a bunch of wireless thin-clients throughout your house. Voila! Cost and energy savings, simple administration, flexibility, and you're still in full control. Yes, this is a geek solution for now, but give it another 5-10 years and you'll see this sort of thing popping up everywhere in the mainstream. Heck, one of your thin-client devices may be your Playstation 4.:)
ps.) I'm making the assumption that you're talking about home use, but there are cases where similar setups can work well in businesses.
KHTML is an incredibly clean framework. It's hard not to look messy by comparison. It's not terribly fair though, WebCore is not a "messy" framework by any means.
That still doesn't answer my question though.. where's the proof? Why/how is WebCore more "messy" than KHTML? If indeed it is, I would have to agree with the KDE devs in this whole argument. Pushing hard for releases does not need to go hand in hand with sloppier code. If the Apple code is truly sloppy, it's only because their developers and/or processes are inferior. If anything, the trade-off goes the other way. Cutting corners today costs you far more time tomorrow. That's always been my experience.
Slashdot Mirror
The open source community at large needs to take off the tinfoil hats and start doing some real development on these platforms.
This is simply not possible. DRM is fundamentally about shared -- but hidden -- encryption keys. DRM software cannot be Open Source because then you'd be able to see the keys or extract them from the datastream. The only way for DRM to "work" is to have a complete chain of hardware and software for which users have no control over. For example: hardware which will only operate and exchange DRM keys with cryptographically signed software. That software cannot be Open Source and it cannot run on an Open Source operating system kernel. (otherwise, you could just probe memory and find the secret key) There is no middle ground here. It's physically impossible to implement DRM in Open Source software.
Having that said, some technologies, such as TCPA, are indeed dual purpose. Let me give you an example. If the user -- rather than the hw/sw vendor -- controls the encryption keys, he/she can password protect his/her data or cause the hardware to run only binaries that he/she has signed. This is not DRM; it's just a form of hardware-based data security. Of course, TCPA can also be used for evil -- when vendors have their own keys hardwired into the chips and the user cannot access them. This use of TCPA allows for all the bad stuff: hardware that will only run a certain vendor's OS, media that will only play on certain "trusted" hardware and software, etc.
I sort of see rails as occupying a middle ground between PHP and a java app server. You get the structure of a java framework with the ability to know stuff out of PHP.
That's a surprisingly accurate assessment for supposedly being "uninformed" about the topic. I have PHP and Java background and have recently researched Ruby a bit. At this point, Ruby would now be my choice over PHP for all but the lightest-weight jobs. If Ruby improves in the area of templating and component-based UI frameworks, it could knock PHP down quite low on the list and start to compete in the low-end Java arena.
Java app servers, on the other hand, still run in an arena that the scripting languages can't begin to touch and by architectural nature never will. What is a more interesting comparison is modern lightweight Java tools (like Spring/Hibernate) vs. Ruby. These Java tools have a ways to go regarding loosing additional XML baggage, but they are still a significant improvement over current heavyweight J2EE app servers. What is most interesting is the convergence. Java tools are rising to the challenge of becoming simpler. Even the EJB 3.0 and J2EE 5 specs are heavily geared towards this goal. The question becomes: If Java tools get closer to the simplicity of scripting languages without losing the power of their architecture, where is the incentive to use scripting languages? Conversely, the scripting languages have simplicity nearly mastered but they have no headroom architecturally.
Yeah that otherwise being that new game, or dvd copying app, or accounting package they bought from the store not installing...
You're missing the point. People will use whatever comes pre-installed on their computer. Companies will be forced to write for Linux as a result. Now, the reason why Linux will come pre-installed should be clarified. Businesses are the first market for Linux and are where all the change will originate. The home desktop will change as a byproduct. Home users will want the same thing they use at work. Incidentally, this is why anyone who knows what they're doing is targetting the business market with Linux, not home desktops, at this point.
Sorry to bring this up over and over.. but an installer for 3rd party commercial apps that will work on at *LEAST* half of the installations/distros out there, and in future versions is what is needed for *ANY* hope of a widespread linux desktop...
You're assuming that not all of the software that consumers need will come packaged *BY* the distribution. You're also assuming that consumers will use a plethora of Linux distros instead of one or two popular ones. (Most distros are not aimed at home consumers, and it won't matter if they're not "supported" by games, etc.) Third, you're making the assumption that proprietary* software will still be popular by the time Linux/OSS has taken over in the business world and started transforming the home market.
* You used the word "commercial" when you really meant proprietary. Much of the best F/OSS is commercial but that doesn't make it proprietary. Before you start going on about how nobody will make money on open source games, consider that the real value in video games today is found in online services and associated graphics, storyline, levels, and multi-media content.
IMHO OSX brings enough unix for those that want it.
If you think people were previously going for Linux only because it's "unix-like" you're entirely missing the point.
Windows is king because you can install a piece of software written for windows 95 (ten years old) on windows XP.. generally without issue.. that can't be said for Linux.
Almost nobody actually does this, so the point is irrelevant. Home users don't run Windows because they need to run old software (heck, most can't even find all the disks that came with their latest computer). No, they run Windows because it came pre-installed. Then they find additional software to run on it.
OSX is largely the same for the past 5 years... the simple fact is linux is a great server platform, it downright sucks as even an option for mass consumption
Face it: OSX is not a replacement for Linux on the desktop and it never will be unless Apple makes it 100% F/OSS. OSX is a niche product that runs only on expensive Apple hardware. Linux has a far greater chance of taking over the desktop market than OSX at this point -- not because it's currently as polished but because it's not tied to a single vendor. But to be fair, I don't think Apple wants to create a mainstream, Windows-killer product with OSX. They've always been satisfied to provide a decent product to a smaller, loyal customer base.
If everything could ultimately be tracked back to you eventually, things like spamming, virus distribution, defamation, on-line fraud, and numerous other harmful behaviours would be dramatically reduced.
Identiy systems are the wrong solution to legitimate problems.. Spam and viruses are technology problems and thus can be fixed by technology. (My spam filter eliminates about 99.5% of junk and I don't deal with viruses on Linux or OSX machines) Defamation can already be handled through the same legal means as offline and really is not that big of a problem anyhow. (anonymous sources online aren't exactly considered trustworthy to begin with.) The vast majority of online fraud could be eliminated if all credit cards simply had rotating pins or any other secondary verification scheme. (like "Verified by Visa") I don't know what the "numerous other" harmful activities you refer to are, but I can't think of anything that could be suitably prevented using identity systems.
Frankly I don't want a universal "tracking cookie" that I can't turn off. The ramifications would be far worse than any problems partially alleviated. In fact, it would probably spawn new types of criminal activity. IP addresses are not anonymous to governments, but they are reasonably anonymous to illigit marketers, identity thieves, stalkers, etc.
I think you may be a bit out of touch with the "average user". If a Linux system "just worked" then yeah, maybe they'd choose it over OS X or Windows. But Linux is never going to "just work" that way.
I think you are a bit out of touch with the fact that nearly all users simply use what is provided to them -- whether by Dell/HP/etc., Apple, or their employer. The notion that Linux must be perfectly easy to install so that people can convert their old machines is somewhat nonsense. Most consumers just throw out their computer and buy a new one. If that new computer has Linux instead of Windows, they'll use it. (and half will think it's a new version of "Microsoft" until someone informs them otherwise..) On the other hand, I wouldn't put it past Linux to start catching on as a way to re-use old consumer PCs where Windows has been destroyed by Spyware or its own doing. If you're formatting the drive anyhow and don't care about old data, most modern desktop-centric distros will provide a useable working environment with minimal knowledge and will detect all major hardware.
The mere existence of multiple windowing systems means that applications will be targeted at one of them. Sure, if the average user decides he likes Gnome best, he can still use KDE applications, but the little inconsitencies in the interface will start to wear on him.
First of all, the consistency is no worse than Windows software, where almost every program today has its own custom widget set and/or bitmap themeable GUI. Office 2003 is not even consistent with the Windows XP interface -- nor is Windows Media Player, nor iTunes, nor AIM. This is not a major issue to most people. They're used to it. Sure, it's an eye sore to those with asthetic taste, but it's not a show stopper. I would go as far as to say Linux GUIs are more consistent for the most popular software.
The cut and paste issue is likewise a non-issue today. Go try it yourself. Cut from KWrite and then paste via Ctrl-V into gaim, gedit, OpenOffice, Firefox, and KWord. No problems whatsoever. This argument is bunk. It was valid 5 years ago, but not today.
Linux still needs a lot of work to be that thing.
I often say the same thing for Windows and Mac OSX, though OSX may have a slight lead at the moment. The whole consistency and usability issue is going to keep getting better thanks to work by the freedesktop.org group.
That's all nice, execpt that for same dozens of options in RoR you don't need any XML.
:)
They aren't the same dozens of options. ActiveRecord is catching up, but it's not a feature equivalent to Hibernate yet.
Of course, many real-world business apps require far more than just a CGI-based front controller and an O/R backend store. After further study, RoR indeed looks like a great tool for developing a certain breed of web apps -- the typical e-commerce, blog, cms, etc. variety. I would use it in place of PHP any day for this sort of app because it really does everything right. However, these examples are lightweight web apps which can be made almost entirely stateless and which do not have complex transactional, auditing, scheduling, and security requirements. Most business apps do have these sorts of requirements and often their use cases dictate a significant amount of application state. RoR is not up to this task by its very nature as a CGI scripting language. It is request driven and all state disappears upon completion of the request unless it has been persisted to the (comparatively slow) database backend. Scheduling is likewise impossible.
It's funny to observe mazochists fighting for their passion
It's funny to observe scripting language developers claiming their language of choice is the right tool for every job.
Your faulty illustration demonstrates precisely where the article's comparison goes terribly wrong. Those 38 lines of XML required by Hibernate give you the ability to specify dozens of options and features that ActiveRecords doesn't have. And those options are actually required when you're not just writing a toy application or tech demo.
Of course, it should be mentioned that most likely the Java IDE you are using will automatically generate that Hibernate XML for you. You can hand tweak it later, but the hard work is already done.
it's very likely that they're going to grow at a fast rate and add a lot more music to their portfolio.
Not likely. They have near-zero mindshare and their artists are entirely unknown. What is going draw people, especially pop-culture-inundated students, to this tiny new catalog? Absolutely nothing at the moment.
The problem with all current attempts at promoting independent media is that everyone assumes they can use the same methods as the big guys -- like actually selling music, whether on CD or via download. They're thinking way too much inside the box. You would think that after thousands of failures, independent artists would have realized that they've continually put themselves into an obvious catch-22.. Most people only buy music if it is popular. Music cannot become popular without being heard. If you sell your music, only people who buy will hear it. If you're not popular, nobody will buy your music. The major labels break out of this catch-22 via marketing and controlling influence over all popular broadcast media. In other words, they force music to become popular so that artists can make money. Now, once an artist is popular, they no longer need big labels, but by that time they've been contractually entangled and it's too late. Independent media has almost no marketing and almost no influence over popular broadcast media. The only way for a new independent artist to become popular in the mainstream is to give away their music in an effective manner. After they are popular, they can make money however they choose -- by selling albums, concert tickets, merchandise, etc. Of course, most new artists think, "If I give away my music, I can't make money." But the opposite is true. If they try to sell their music at the beginning, they will NEVER make money or else it'll take them decades to become marginally popular.
But how does one give unknown music away effectively? Many have tried before but never with much success. Why? Because they've all done so passively. Simply putting up a website or putting songs on a P2P network will not effectively give away music if it is not already popular. These are good tools once momentum starts to build, but they don't solve the problem. The catch-22 simply becomes: People will not download your music if it isn't already popular. Sure, the handful of people who care about independent music might stumble upon it, but there aren't enough of these people to meaningfully support artists. The only way to attain popularity with unknown music is to actively promote it. The method depends on the audience and environment, but it always involves investment of time and money. This is no different than starting a personal business. There are always upfront costs and sometimes even a small loan is necessary. But where there is no risk, there is no reward. It would seem that most independent artists today are terrified of risk.
Never underestimate the marketing power of backpacks filled with $0.10 mass-produced CD's labeled "feel free to copy for all your friends."
I love java and hibernate and all of the powerful ideas it introduces and brings to the table, but RoR just makes things so easy and fast. I don't know how easy it would be to write something huge in it..
.net anymore. Unless you like writing non-MVC apps :)
.NET has become a very strong competitor to Java for mid/large scale applications. ..So beware of becoming too smug. And there's nothing saying that .NET apps are non-MVC. The next several years are going to have developers on each side working hard to surpass what the other is doing. If Ruby wants to compete with the big dogs, it's going to have to grow up really quickly and get some real tools in its belt. Right now, Ruby is not something you would use to write a large, complex enterprise app. At this point, the Open Source community would be far better off rallying behind Java (aka. a Free "java") than any scripting language or immature newcomer like RoR. Java needs to be improved, but it already does an enormous amount right.
RoR makes easy things easy, but Java makes hard things possible. (You could also insert Python, Perl, or PHP in place of RoR and that statement would be equally true.) The "alternatives" to Java are all missing an O/R tool as powerful as Hibernate, an AOP/IoC framework as powerful as Spring or AspectJ (if they have one at all), and a UI framework as powerful as Tapestry or JSF. The IBM article in the parent post is pretty terrible because it compares Java vs. RoR for ultra simple web applications which could be feasibly implemented in ANY language. It wouldn't surprise me if RoR is an excellent alternative to PHP, but it's nowhere near an alternative to Java for that which Java does well.
I don't see any room for
Largely through copying of what has worked with Java and friends,
As long as it is well-programmed and optimised, I always welcome this kind of bloat with open arms.
:)
Modularity doesn't hurt either. Bloat is your best friend as long as you can turn it off.
Gnome too configurable? You must be talking about Gnome 1.0... not anymore.
Ironically, GNOME is no less "bloated" than KDE in terms of memory usage in a typical desktop session. In my experience, KDE is simply more efficient. Both environments require a relatively modern machine to perform well, but KDE gives you far more features and configurability in the process.
If you're asking me, it's because KDE is less driven by politics and more by what users want.
Of course, the problem is most prevalent in Java software, which the KDE developers thankfully seem to be avoiding. (I remember a remark someone made about Eclipse... 512MB RAM = slow, 1GB RAM = fast... which is ASSINIE for a text editor).
.NET/Mono or whatever. With a large application, that VM overhead shrinks rapidly and becomes negligible. And of course, VM's provide very nice security features as well.. again something well worth their overhead memory cost.
.NET on either machine). I've grown to love the so called "bloat" - that is, it seems that any time I think to myself "I wonder if Java will let me do Y without reinventing the wheel" I find out that I'm not the first to have thought of it; it's actually implemented! (..same analogy applies to Java as KDE!)
Eclipse is not a text editor. It's an extremely powerful extensible IDE and as such it is quite efficient and useful. Eclipse saves developers an incredible amount of time and that time is worth a few orders of magnitude more than the cost of the extra RAM it uses over a lightweight IDE. Given the cost of a comparable commercial IDE, the RAM cost is absolutely laughable. Incidentally, the number you quoted is quite exaggerated as Eclipse runs perfectly fine on a 512MB machine for most purposes. Of course *any* serious development machine should have 1GB+ anyhow given how cheap memory is today. If your company can't afford $50 to make you vastly more productive, you'd better start looking for a new job quick!
As for Java in general, KDE developers are not "avoiding" it. It's just not the right tool for developing lightweight DE software. Java is neither slow nor bloated when used in the context for which it was designed. The mythical Java bloat is simply the memory overhead of the JVM. You'll have that in any managed code environment so get used to it because it's the way of the future for many types of apps -- whether Java or
I run Java both at work and at home, on decent machines, and I find the performance to be excellent (certainly faster than
It's not as evil as it may seem.
No, it is as evil as it seems. It will hopefully fail as a result and leave a void to be filled by DRM-free open source software. But it's still evil in and of itself and there will likely be many casualties in the ensuing battle against freedom and innovation.
"..But this will be good for linux and open source in the end."
The only way that Open Source is ever going to take over the media content scene is if artists and movie producers start going independent en masse. Linux is already largely "cut out of the content market" in the US because of 1.) bogus patents related to popular (though not necessarily superior) video and sound compression formats and 2.) DRM schemes which are trivially circumvented but for which tools to do so are now illegal to distribute in popular Linux distros. For all practical purposes, Linux already can't play popular media files in the US. Granted, this doesn't stop the experts, but it does stop the casual user and is therefore a major impediment to Linux on the desktop.
It's this simple folks: The only answer is independent media. Hollywood will push DRM till the day they become irrelevant and people will buy it up because they won't know any better. But it's going to take quality alternatives.. not fan films.. not crappy garage/bar bands. Napster, MP3.com, and friends ultimately failed because they never lived up to their promise -- to actually provide an alternative distribution medium for quality content. All they would have needed to do is foster one quality band into the popular music scene and hundreds more would have followed. The RIAA would have been history almost overnight as bands suddenly realized they no longer needed to "get signed" by a big label to rise into popularity. But instead everyone was enamoured with free beer instead of free speech and P2P turned into a giant stupid warez scene. There's still hope, but time is running out.
I can see Apple gaining a wider audience on the other hand. They're moving TOWARDS open source, not away from it.
Apple is using Open Source only where it benefits them directly. It's better than nothing, but they're hardly "team players" in the Open Source community. MacOS X is very much designed with platform lock-in in mind. Simply ask yourself this: Why is Cocoa not Open Source and not cross-platform? Apple also had a chance to jump on board the Linux train but they instead chose to do their own thing and not play along.
Public key encryption is used to ensure only the key holder can access it. I can copy the encrypted file to whatever device I like that can read and act on my key. Without my key, it won't work.
You don't seem to understand how public key encryption works. In your scheme, devices can only decrypt the files if they have YOUR private key. But if you hold and control the private key, it's no longer DRM because that private key gives you access to the non-encrypted data and you can do whatever you want with it at that point. DRM is always, without exception, based upon a shared secret. Somewhere, whether it's in software or hardware, there's a master decoding key hidden. DRM is by nature incompatible with Open Source because of this. Always has been, always will be. Either you have control over your own hardware/software or you don't. There's no middle ground.
Say we disbanded copyright for software tomorrow, but continued to permit liability disclaimers - then where would GPL be? That's right - it'd be just another BSD license. People who add GPL to useful code prop up the existing copyright structure..
The only reason why GPL exists is because it is necessary as a weapon against copyright abuse. So you're correct with the statement that without software copyright we'd wouldn't need GPL. But the situation isn't going to change anytime soon. If it does change someday, great.. we won't need GPL anymore. Until then, GPL preserves freedom better than BSD and provides a temporary solution while copyright is being modernized.
I like the idea of keeping my code private, via the BSD license.
GPL doesn't say you can't keep your code private. This is a common misconception. And if you're not sharing the code of the software you distribute, you're not going to be using GPL *or* BSD.
By what process can the mess made by the USPTO regarding software patents be corrected, while still rewarding those few innovators whose genuine software patents can be acknowledged?
Anything deemed a "genuine" software patent is completely unusable to OSS for 14 years. Given that the ideal future is one where all software is Open Source, do you really want to go there? There's no "good" solution to software patents. They're all bad. They all hurt innovation. They're all incompatible with Open Source development. Software, like science and literature, is an evolutionary field where knowledge arises as a natural progression. In it, there is no such thing as a truly novel idea.
Which doesn't sound like doing it for the greater good which open source software is many times made out to be.
The ultimate "greater good" in Open Source is that all software eventually becomes Open Source because that is what is best for technological progress and for the good of society. BSD-license-using folks can't see past the current state of affairs in the software industry and thus assume that we actually need proprietary software to begin with.
The reality is that Open Source movement has simply not yet reached the tipping point. Today, there is still incentive for companies to stay proprietary, but this will not always be the case. At some point it will actually be easier / more economically beneficial to go Open Source in every case. We will witness the final death of the software vendor and rise of the service provider. Life will go on. The software industry will continue to grow. It'll just be on different (more efficient, more fair) terms. And fortunately for developers everywhere, it's pretty near impossible to monopolize a services industry with minimal barrier to entry.
I am particularly fond of it for libraries, frameworks, APIs, etc.
I definitely agree. LGPL for libraries/APIs helps to strengthen the foundations of all our code. I would much rather see a proprietary developer use a LGPL library than a proprietary library. Why? Because there's a pretty good chance they will end up helping to improve and/or debug it in the process. If someday that proprietary developer decides to open up their code, it will immediately work with our Open Source libraries. Granted, I'd rather not see proprietary developers at all, but hey.. embrace and extend right?
Of course, I'm 100% for GPL for end-user software. Otherwise you're just giving away the farm and inviting freeloaders. If somebody really wants to go proprietary, they can dual-license your code and support your future efforts.
That out of the way, capitalism is about capitalizing labour; that is, putting people together that create more value than if they worked seperately.
..it will be in the interest of those who wanna make a sh** load of money to patent software based on the source, not a description of what the thing does.
Implemented properly, Open Source is fundamentally about transforming the software industry into a pure capitalist labor market which is free of most artificial barriers and regulations. The key is really how to pool resources so that those who need software can pay for its initial development. (the capitalist value is in this initial development labor, not the final product which is freely shared and replicated at no cost)
At first, it sounds like a free-rider problem waiting to happen, except the reality is that:
1.) The largest percentage of software produced today already involves either contracted or in-house development.
2.) In a highly competitive market, a cheaper solution that gets the job done is usually the best option. Even if ones competitors can partially free-ride on it later, they're already far enough behind that it doesn't matter. Either way there's always the cost of implementation, customization, and internal support -- these don't go away just because something is Open Sourced. (If you're really smart, you can spin off a new division and make money supporting the software you wrote or enhanced in-house!)
3.) Paying for Open Source development doesn't necessarily mean starting a new project from scratch. It could be development of one needed feature in an existing project that is otherwise satisfactory.
Hm.. I'm not quite sure what you're getting at here. Copyright is adequate for protecting a particular implementation whether the source code is open or not. Patents have no logical place whatsoever in software.
And it doesn't take a MS guru to setup a secure "full-featured mail or file/domain server" using Windows?
:) Good luck learning it.
It takes experience, but not necessarily a high level of specialized expertise. You can grab any of hundreds of books available on Windows Server admin and be up and running in a day at most. You really can't say that for a Linux server purposed for Samba or mail and running a stock free distro like Debian or Fedora. Assuming no prior knowledge of the software (only general Unix admin skills) it can easily take a solid week to figure out how to properly install and integrate say.. Postfix + Cyrus + OpenLDAP + Amavis + Spamassassin + OpenXChange as a real working solution comparable to Exchange2003 for a corporate office. If you're a Windows admin on staff at some company, are you going to spend that much time on a project not guaranteed to work due to your non-Unix-guru status? Probably not.. even if you toy around with Linux at home for kicks or to stay up on the latest. This is what I'm getting at. Today's Windows admins need to be the target audience of OSS. We HAVE to meet people where they're at or it's a no-go. Regarding security, you shouldn't have to be a guru on ANY platform to achieve security. If you do, it's a design failure. Both Windows and *nix currently fail in this category. That's why there's a growing market for security consultants.. companies don't necessarily trust their own admin staff to be perfect!
Commercial software and FOSS both have their places.
FOSS can and should be commercial software. It just isn't proprietary. (I'm increasingly trying to get people to use this terminology instead of the inaccurate commercial == proprietary)
Firebird , which is based on Borland's Interbase. Though I've only recently installed it I hope to learn it soon.
True.. I haven't had time to look at it much but should have made mention. I don't know offhand how it compares to PostgresQL, though I've little doubt it is ahead of MySQL in most areas.
It already happened. The meteor is the GPL. You cannot do business as usual (if you are a rapacious beast, that is, intent on devouring all in your path) with the GPL. Microsoft has come to an almost dead halt in its efforts to fight Free and Open Source Software. Everything they have tried has failed, to a greater or lesser degree.
.NET. Fact is, OSS has made virtually no impact on the desktop or small/medium business server so far. This isn't going to change unless there's some fundamental rethinking of the whole OSS process. How so?
.NET at this point and even then it's a close race. The OSS community needs to fully embrace and support Java.
Open Source has made important inroads but lets not get carried away and start the celebrations right in the middle of the battle. It's all quite far from over and MS has plenty more tricks up its sleave with Longhorn, Office 12, and
1.) Every significant end-user software project MUST be commercialized. The current rate of progress is insufficient to keep up with the proprietary giants, let alone have time left over for significant innovation. Volunteer / hobby labor is not sufficient. Major projects like OpenOffice, KOffice, Gimp, Gaim, Inkscape, Scribus, Mozilla, etc. which all aim to meet "mainstream" needs in turn need full-time, paid developers. Some already have them through corporate sponsors, but they need more.
2.) OSS developers need to focus on real solutions and not just raw materials that somebody else might find a use for. This is one of the prime reasons why existing OSS solutions are passed over.. they're far too costly to implement for smaller organizations. As example, it shouldn't require a Unix guru to set up a full-featured mail or file/domain server -- but it currently does. (Or you can spend nearly as much as the MS solution by going with a proprietary Linux distro to integrate the raw materials for you.. but then where's the benefit?)
3.) Many OSS developers need to quit wasting time with low-end technology like PHP and MySQL and move on to Java and PostgresQL. As a former PHP4/5 developer, now Java developer, I can honestly say that I'll never go back. PHP/MySQL definitely has its place for simple web tasks (as it was originally designed in its early days) but too many people believe PHP is something it's not and architecturally can never be. Open Source Java tools completely blow away everything that exists for PHP when it comes to doing real business application development. (incidentally, business apps are a major weak spot in the OSS landscape) It is unfortunate that people like ESR have poisoned the OSS world with lies about how Java should be avoided at all cost regardless of the fact that it is often the best tool for the job. Other than the trademarked name, Java is no more proprietary than C/C++. It's a language.. a tool. If the only good Java implementations are proprietary ones from IBM and Sun that's the OSS community's fault for not meeting the need as with other languages in the GCC suite. Lets put it another way: Java is the only real competitor to
Solve these three problems and we'll see the true revolution happen. Ignore them and OSS will be destined to forever satisfy a niche market.
I don't know about anyone else, but my biggest gripe with X performance these days is the rendering speed of RGB subpixel anti-aliasing. (at least on Radeon cards, which is all I have..) It's not unusably slow, but it's highly noticable and makes everything feel sluggish.. especially scrolling.
Curious? Do a quick test:
x11perf -aa10text
x11perf -rgb10text
On my system, running X.org 6.8.1, regular AA text is about 8x faster than RGB-AA. RGB-AA produces no slow-down in Windows on machines I've checked, so it must be a driver or implementation issue.
Windows has SUS, whereas Linux doesn't seem (excuse me if I'm wrong) to have any kind of distributed patch management for large businesses.
/diskless-root
Windows has one distributed patch management system. With Linux/BSD/etc. there are multiple approaches depending on what works best for your organization. Every Linux distro I've used is quite flexible in this regard. In my opinion, the ultimate is diskless workstations running off a fast file server (SCSI RAID, 1000Bt network). (30-40 workstations per server, replicate servers as needed) You can use local hard disks for caching if you like, but the ease of administration is the same.
Advantages:
- workstations are stateless and can be swapped out on the fly with no syncing
- reduced heat, power usage, and noise from workstations
- no need to either leave machines on at night for automated updates or initiate updates upon startup
- guarantee that everyone is using the exact same software
Updates are pretty much as simple as running a package manager on the master shared filesystem root used by the diskless machines:
chroot
apt-get update; apt-get upgrade
Do you also look forward to not having the option of "owning" any of the software you have on your machine?
:)
Who says you won't be the one running the server? Desktop-centric computing is beginning to die out with the evolution of the web and embedded devices. But that doesn't mean you'll have to pay for ASP's instead. Stick a fast Linux server in your basement and a bunch of wireless thin-clients throughout your house. Voila! Cost and energy savings, simple administration, flexibility, and you're still in full control. Yes, this is a geek solution for now, but give it another 5-10 years and you'll see this sort of thing popping up everywhere in the mainstream. Heck, one of your thin-client devices may be your Playstation 4.
ps.) I'm making the assumption that you're talking about home use, but there are cases where similar setups can work well in businesses.
KHTML is an incredibly clean framework. It's hard not to look messy by comparison. It's not terribly fair though, WebCore is not a "messy" framework by any means.
That still doesn't answer my question though.. where's the proof? Why/how is WebCore more "messy" than KHTML? If indeed it is, I would have to agree with the KDE devs in this whole argument. Pushing hard for releases does not need to go hand in hand with sloppier code. If the Apple code is truly sloppy, it's only because their developers and/or processes are inferior. If anything, the trade-off goes the other way. Cutting corners today costs you far more time tomorrow. That's always been my experience.