Gpl v3 makes one thing clear: it's all about ideology. If you don't subscribe to the ideology (e.g. because you run a for profit business instead of a commune) you should use a different license.
Actually the v3 is a bit confusing. Licenses don't need upgrades but clarifications if there is a legal error in them. v3 is different from v2 and not necessarily an improvement depending on your point of view. The GPL is generally understood to be v2 (and controversial enough in that version). v3 suggests it is the same thing with some minor clarifications. Clearly that is not the case, the changes are not minor and v3 might turn out be quite a bit more controversial than v2.
The nice thing about the feature matrix on that site is that it clearly illustrates the problem with many OSS cms systems: they're mostly low end systems with lots of important features missing. For example wordpress doesn't have most of the features. I use wordpress for my blog but I know the difference between that and a high end cms. Wordpress doesn't have versioning, it doesn't handle internationalization to well, it doesn't include workflows, it doesn't support custom forms, it doesn't support anything else then mysql. Just to mention a few of the big ones. Again, I actually like wordpress but I know it is not in the same league as most really good cms systems. But then it is really good for running a blog.
Of course there are some highend oss cms systems as well. I'm not criticizing them all. But most of the usual suspects that surface in this type of discussions (wordpress, cocoon, etc) are pretty low end systems: good for simple websites and nothing else. They can be adequate if you don't need the highend features but making a conscious decision about that should be part of the decision process. A common mistake is assuming you don't need the high end stuff and then doing a lot of custom development to keep the customer happy.
There's companies making some good money out of CMS system customization. Often they are a better option than inhouse development. If you're going to use OSS because of the cost aspect that's fine but as soon as bunch of your employees need to spend more than a few days of work to get the thing going you've probably made a mistake.
Sure it's not a bad idea from a technology perspective.
Sadly, for Microsoft, it's their own fault that people are not 'getting' their new technology. So far they've done a very good job of getting the brand name out, only they failed to communicate what it is so people started comparing it to flash. And it's going to take some really good, consisting marketing to get rid of that image. I predict sparkle will quickly join the growing list of their failed marketing/technology concepts. By the time tools and platform have been deployed in sufficient numbers to make large scale developer adoption worthwhile, developers will have moved on. Vista (and the associated technology) won't be widely available until next year. Corporate adoption should pick up somewhere near the end of 2007 (and that's by MS own optimistic schedule, I suspect companies will be extremely reluctant in adopting vista). That's two years already. That's the earliest possible moment that a small market for sparkle apps might emerge. But then, why would application developers target such a small audience?
So that rules out sparkle for application development for the next few years. Besides, much corporate development is now browser based and thanks to Microsoft failing to do anything relevant on the browserside for a whopping six years now, that is now becoming a standards based arena. Internet explorer only products are really hard to market nowadays. ActiveX, another failed technology, is now regarded as insecure technology. Microsoft's non standard css and javascript 'features' are now used primarily to work around browser bugs.
The reality is that Microsoft is struggling to get the developers back on their vertical stack of technology. It's not working. They alienated their VB development community, failed to get widespead adoption of.Net client applications and in fact more or less told developers not to invest in.Net 1.x because 2.x was coming and beside vista would have avalon, eh sparkle.
Most encryption solutions suffer from obscurity and severe usability issues. Educating users who don't know nor care about encryption has always been the primary obstacle for getting people to use encryption (which is why most users have never ever heard of pgp and would be clueless if you send them your public key). So harddisk encryption works because it works transparently (if you set it up for your users), email encryption doesn't work because the user has to mess with keys, which he/she won't do. Encrypted usb sticks will work if you can guarantee they work everywhere and that no unencrypted sticks are used. Both of which are pretty much very hard to guarantee or enforce.
USB sticks are just plugged in and are pretty much guaranteed to be not encrypted. Mobile phones present similar difficulty. Most phones have poor customizability and security. In fact users are quite creative in finding workarounds for security obstacles. The primary use case for usb sticks is getting to your data outside the company when disconnected from the intranet/workstation for whatever reason (at home, at a customer, a conference,...). So precisely when security is most important, security measures force users to resort insecure means of getting to their data. Because you set up some unusable vpn, the user will just use the usb stick instead of spending five minutes of presentation time to get the vpn going. Much easier.
So the solution is to reduce the need for transmitting data insecurely: make sure the user can get to his/her files securely in an easy fashion anywhere, anytime. The consequence of not doing so is the risk of users using hotmail, a usb stick or other insecure means to get the data where they need it (and they decide where that is, not you). Security can actually be counter productive if your users have to work around it and do so routinely.
Programmers write really shitty documentation (grammar is an issue, they don't understand the users, they make wrong assumptions about what should be documented and how) and are too expensive to let them do the job properly anyway. Like testing, writing end user documentation is best done by someone else. Let the programmer write code, designs and code comments.
More specifically, debian stable is (really) good for servers that don't need the latest and greatest. It sucks for workstations because you'll end up being one or two major versions behind for the most crucial desktop packages, including significant feature, stability and security improvements that go into these packages.
Debian unstable is good only for non production workstations. Specifically it doesn't have security updates; it will be in a more or less broken state most of the time (which may or may not affect you depending on which packages you use). Debian testing is only slightly better, you still don't get the security updates and buggyness still is an issue. Blindly updating a debian testing install is a ticket to disaster (been there, done that).
What's frustrating for new Debian users is that the Debian developer community is not really that interested in them. If you can get it to work good for you, if you can't RTFM. Also it is a safehaven for the ideological elements in the linux community. You know, the ones that insist on speaking of Gnu/linux. Dealing with the more extremist types in this community can be tedious. Lots of people use Debian for ideological reasons rather than pragmatic reasons. Recently the pragmatic part of the community made a mass defection to ubuntu (debian derived).
I'd recommend anyone looking for production use of debian in a desktop environment to only consider ubuntu. For small scale servers debian stable is a good option: you don't get the bloat of the big vendor stuff and it just works. For large scale servers, use something with support and reputation: red hat, suse are good options and all major vendors support them. Only use Debian on large scale production servers if you are willing, permitted and qualified to run it. Because if the shit hits the fan it will be you cleaning up the mess with noone committed to support your mess other than you.
Actually mysql works fine on windows. I've seen it being used in production and I've run it for about two years for testing purposes. Windows is quite a good choice for running mysql. You get a nice installer which makes configuration easy; there's several good mysql frontends (e.g. mysqladministrator) that make configuration easy and there's commercial support available if you need it.
In general, most oss stuff that makes linux popular runs on windows as well these days (quite often with very good commercial support available and user communities that dwarf their linux counterparts). Basically all of the commandline stuff is likely to already have at least an cygwin port. The more important packages generally have windows specific versions as well (e.g. apache, mysql, openoffice, firefox, python, perl, gaim, php....). Some of the desktop stuff actually works better on windows (e.g. firefox, eclipse).
I'm a big OSS fan and I use windows almost exclusively. Aside from the OS and office (at work), most stuff I use is open source. I prefer linux for server environments, though, but performance or stability are not the reasons. Managability is the big reason for me.
Despite this I'm pragmatic enough to see that you don't want linux unless you have a capable sysadmin available to run it. Putting linux in an environment with a few windows wannabe sysadmins (i.e. most small companies) is just asking for trouble.
They are supporting it in the best way possible: they use an open, standard protocol that so far has been used and developed mostly in unix/linux environments. That's all the OSS community needs. What more could you ask?
Besides, there's no such thing as desktop linux. There are dozens of distributions, window managers, graphics toolkits that are used in basically any combination you can come up with. On top of that, there's different versions of all these components. Which ones of these combinations is desktop linux (answer likely to be highly subjective)? And will the answer to that question be the same in half a year?
A fourth important reason is being able to figure out who chnnged what when and why, sometimes years after the fact. This is something subversion allows you to do easily and it can be really valuable information when debugging some stuff written years ago. Subversion makes this very easy.
If mono becomes good enough, developers might start to target it when developing for windows. Right now that is not the case though: it's not good enough. Mono under windows sort of half works but the tooling, sdk, etc. all assume a unix infrastructure. You can of course develop for microsoft.Net but then you end up with their tooling as well which sort of automatically leads you away from cross platform stuff like mono.
Mono as a porting tool has no future IMHO. Mono as a cross platform development kit does have a future. Or at least the potential is there. I don't see much happening in the community to push it that way. Focus so far has been on the infrastructure level: getting the compiler & vm to work and reimplementing microsoft APIs. And yes there's even a windows build of mono available. Development tooling however is linux only, even though much of it is written on top of mono!. If writing a cross platform mono application on linux is already hard, why would the other way be any easier?
I believe mono as a cross platform development kit can happen but I don't see it happening right now. Development focus has been and continues to be linux only. Like it or not, windows has, by far, the largest share of the desktop market. Being able to support linux is nice but windows support is crucial for application developers (or at least the ones that depend on marketshare for income). Right now mono is a nice tool to develop linux gnome applications. If developing linux gnome applications is your ambition, go for it. If you need to look beyond linux gnome, you need something else for your applications.
I've traveled quite a bit and slept in some pretty shitty places. In the end the only thing that's relevant about a hotel room is whether the bed and shower are clean enough (some nasty surprises I've had in expensive hotels: somebody else's pubic hair in the bed, small bloodstains on the towels, a 'used' toilet, 'dubious' stains on the sheets).
I don't mind if the room is small, as long as my bag and I fit in to it and as long as it is clean. Hotels are mostly about providing a false sense of luxury at a low cost for people who don't get around very much. If you travel a lot, you're no longer impressed by it. Just like air travel had a reality check over the past few years, hotels will have a similar reality check. You can still fly business class if you want to but unless you are an overpaid executive, you'll probably fly economy class and pay for your drinks & meals nowadays (short flights anyway). Similarly, do you really need a minibar, a spacious lobby and an outrageous breakfast buffet? Sure it's nice to have but will you pay for it if the alternative is 50 dollars cheaper and gets you a good enough bed in a small but quiet room? Right now you don't have much choice.
When traveling privately, I always seem to find these inexpensive nice places and when traveling for work the room price is two or three times as high.
Energy is the key issue for this century. With plentiful, cheap energy available, mankind will be doing so many cool (or evil) things. Think hydrating the sahara desert, just because we can. Sure that will take huge amounts of energy but what if that was cheap? Currently, producing sweet water from see water is very expensive, mainly because of the energy cost. So is pumping it from the sea to the sahara. So are many other production processes. In many industrial processes, energy cost currently is the bottleneck. So take it away.
Currently, driven by rising oil prises, the increasing cost of oil production and the exponentially growing demand for energy, there are many research projects into alternative energy production methods, improving existing methods of producing energy and improving energy efficience on the user side. I expect 99% to lead nowhere and 1% to revolutionize the world. We've historically been very good at squashing technical issues on our path. Producing energy is just the latest hurdle.
It is my hope and expectation that we will tackle this problem during my lifetime. Energy is plentiful, we just need to learn how to tap into it more efficiently.
The platform is just something you use to run the software. Select the software first + the technical partner that will implement it for you. By far most of the cost of the whole thing will be in those two things. Hardware + os is peanuts compared to that. Then go with the platform recommended by your technical partner. If it happens to run on both windows and ibm, your ibm skills may be reusable (that's the real issue, isn't it?). That should be decided based on cost of ownership.
It's stuff like this that makes the big software corporations invest in patents. Companies like google and microsoft don't draw significant revenue from patents and actually invest heavily in research. But having patents guarantees that they won't end up sueing each other. It's a defensive thing and it has gotten way out of hand. I work for a large european company that files lots of patents (Nokia) and we are very much into this thing. European patent law doesn't allow many of the patents we file in the US. Just recently we got sued by this small company from the US. Filing patents is our primary defence against this. Our money comes from selling phones, not intelectual property licensing.
With the US patent law and office deliberately (this was/is lobbied for) weakened to the point where basically any brain fart may be patent pending, people are patenting everything they can think of with absolute disrespect to such outdated things as prior art, originality or even cleverness. It doesn't matter if an idea is stupid, based on existing ideas and stolen: a patent gives you the right to sue. The legal process is guaranteed to be lengthy, complicated and above all very expensive. The patent office rubberstamping anything they stumble upon ensures a steady stream of revenue for a growing group of companies who, in all honestly, have never lifted a finger to do anything remotely resembling research. Their revenues are based on bullshit portfolios of patents. Google is just the latest victim. Luckily they have the muscle to fight back. Many truely innovative companies don't.
The rats of the IPR industry are becoming an obstacle for innovation. Large corporations are now starting to feel this pain (e.g. Google, IBM, Nokia and Microsoft have all recently had to deal with lawsuits from insignificant IPR only corporations). The problem with IPR only companies is that you can't countersue. In other words, your patent portfolio is worthless if you are sued by one of those companies. It is my hope that these companies will get smart and start lobbying against software patents instead of in favour like they have done in the past. Just today I joked to a colleague that Nokia should quit selling phones and focus on the Nokia Research Center I work for:-).
The real lesson is of course that once again mr buffer overflow strikes (don't implement anything in C if it needs to be secure). This time it's on windows. On windows it is bad because a lot of people use windows so any bug presents hackers with a huge opportunity to affect millions. On linux, buffer overflows occur just as often (or more often according to some sources) but are much harder to exploit because of the diversity in linux installations. Essentially it is pretty hard to find a meaningful number of linux computers with the same unpatched bufferoverflows, finding linux computers with unpatched bufferoverflows in general is easy. Linux offers great security through obscurity. The linux desktop (if there even is such a thing) is so rare and likely to be different from most other linux desktops that it is unlikely to ever be the victim of a coordinated effort to exploit a buffer overflow. It would basically require a large amount of linux users running the same version of the same software compiled with the same compiler for the same plaform. The total amount of linux desktop users of course is hardly interesting to begin with.
.. And not the other way around. I'm a developer, I tend to be understanding of sysadmins: as long as they give me local admin rights to my machine. Especially in larger organizations, sysadmins can be real pain. Often they don't know (nor care) who you are. Getting anything done requires getting a helpdesk ticket, which will end up on some desk. Then maybe three days later some guy picks it up. That just sucks if you are trying to get your job done.
At my current job one of the first things I did was request local admin rights. I think the guy must have understood that I'd be inserting a lot of helpdesk tickets in his queue if they refused the request. In any case, I've been pretty happy since and haven't had to bother them since.
Eight years ago I was living in sweden (I'm dutch) and there was this cool new thing called streaming video. You could watch for example the dutch news in 50kbit/s. Fast forward eight years. I now live in Finland. I have a nice broadband connection and aside from the news (now in ok-ish 500 kbit/s) there's still not that much interesting to see on the net. There's lots of crappy stuff out there but mostly you still can't (legally) watch a pay per view movie, series, etc. The bandwidth is there, the technology is there but the content providers aren't.
Sure there are lots of local cable operators and telcos that offer you a very limited choice in video channels and pay per view stuff but none has gone online and offered their services to whomever has the bandwidth. I'd probably pay for 20mbps instead of the 1mbps I currently have if that would get me high quality content at a reasonable price level. Right now it's just not there.
I can get a premium selection of IMHO shitty digital channels (discovery*, CNN, etc.) for 25 euro per month or I can put a satelite on my roof and receive hundreds of channels, including most channels from my home country for about 10 euros/month. I'd gladly pay 10 euros per month for the same content over an internet connection (provided the quality of service is good enough).
There were always enough loopholes in the law before, during and after the patriot act for the various agencies to do whatever they wanted. The patriot act was all about publicity. Bush had to show he was doing something. It worked, it got him reelected.
I admire the strategy. It's a brilliant example of thinking out of the box. It pissed everybody off and that's exactly what was needed to communicate the illusion of leadership.
It also did a lot of dammage to the legal system, foreign relations and the actual ability to fight terrorism effectiveley. Really, pissing of allies is not a good idea in any kind of war and Bush has done his best to do so even with his closest allies (e.g. the UK, Poland, Italy, Spain).
That's why the patriot act has to go now. But that's not part of the strategy. Exit strategies are always the weak factor in the Bush administration. Whether you look at iraq, the economy (budget deficit, pensions), environment etc. Each time the strategy is accepting long term dammage in exchange for short term results. The average voter has an attention span of a gold fish so the future is irrelevant. It's a very cynical form of opportunism. Bush is an idiot, but his cheerleaders aren't and they are pushing this agenda with full knowledge of all its long term effects. They just don't care. The only problem now is that some of the long term effects are showing up a few years ahead of schedule. The iraq stategy is back firing, the economy continues to be weak (despite all the spin put on the statistics), allies are complaining loudly and even the environment is back on the agenda.
Bush is history though. He's become a liability for the upcoming election which will destroy the republican party majority and what we are seeing now is dammage control. It might even work! Again the strategy is brilliant: get all the negative stuff in the paper now so people will have forgotten about it when the elections dominate the frontpages. Cynical, effective and brilliant.
The following presidential election he'll have to go anyway and by then his successor will do his/her best to disassociate himself from the long list of mistakes of the previous administration. That's three long years from now, plenty of time for competent campaign strategists to rewrite history. Bush has simply been ejected from the republican party's strategy. And that's the best news I've heard in years.
Yes, the process makes use of the fact that internal combustion is a particularly wasteful process that transforms most of its energy straight into heat instead of movement (ultimately 100% is transformed into heat of course). Apparently the efficiency gains of injecting hydrogen into an internal combustion engine are more than enough to compensate for the energy lost in generating the hydrogen. Amongst others. the fuel burns more completely (instead of unburned particles being ejected straight into the atmosphere).
Yes, my standard adsl line can do 8 mbps now and 20mbit if I upgrade to sdsl. A standard harddisk would currently do 400 MB. Using mpeg4 (crappy mpeg4 = 512 mbit/s, dvd equivalent mpeg4=2mbit/s, hd mpeg4=10mbit/s) that's good for a few hundred hours of dvd quality video. As you note, mpeg4 and similar codecs scale up nicely and full HD content can be stored and streamed at about 10 mbit per second. If you insist on storing that level of quality, that is perfectly feasible as well on todays harddisks. You basically trade space for quality. Most people I know don't own more than 100 dvds (about 200 hours).
So lets say 300 hours HD quality is 10000 GBit. Divide that by 8 (bit != byte) and you have about 1.3 TByte (rounding up here for the sake of the argument). That's a lot of storage but definately in reach for consumers these days. But then if you can own 300 HD quality movies today, buying the necessary storage to store that won't be an issue. Of course we are years away from being able to actually go out and buy 300 different movies in HD format and by that time 1-2TB of storage will be pretty common in pcs.
But then storing video locally isn't even necessary when you can stream it any time any place any where.
For me digital content distributed any other way then through a network is a thing of the past. My standard dsl connection is perfectly capable of streaming HD video content. A single consumer grade harddisk is capable of storing hundreds of hours of HD video. But why store stuff clientside at all? Just stream the content to my tv when I want to watch it.
I have some experience coordinating releases of a software product. A key thing I have come to realize is that developers don't understand that last minute patches cause more problems than they solve. Inevitably something they regard as important creeps in and that's when you need to just say no. Convince me it's critical (stuff breaks down visibly, data is lost, etc.) or wait until the next release. I've seen this go wrong more than once. Some dork commits something 30 minutes before the release and a week later we're handing out patches for bugs that fix introduced. Unlike OSS, delays are usually hard to negotiate in a commercial setting
With a product as complex as a kernel you need lots of time to properly test and integrate stuff. A kernel release needs to be stable & reliable. Last minute changes with unkown impact are unacceptable unless they fix something that absolutely needs to be fixed.
The git scm tool that linus uses actually supports this development style very well. Developers develop and send in patches to a central repository. Linus pulls the important patches and patches his private repository for a few weeks and then locks it down for testing. That's why he can afford to tell developers to wait or adjust to his schedule.
In this respect he is quite ahead of the clearcase/cvs and svn using masses. These tools do not support this kind of development very well. The mental model of the developers is still that they need to get their stuff in the trunk asap. With git the model is get your patch out, have it tested, optimized and when it is mature and ready Linus will merge it when this fits his release schedule. For complicated changes this process should be slow or otherwise Linus ends up doing the work that should have been done before the merge.
This model is way better than freeze trunk, tell everybody to not do anything for a few months and then release.
Yes it's different than what you are used to and no you can't do most of the things you cite (a few you can actually). Most Java programmers don't see that as a problem. Programming Java simply works differently than programming C. If you apply your C skills to Java or your Java skills to C, you are very likely to write crappy software. Both languages require different approaches for solving the same problems.
BTW. the StringBuffer class solves your problem quite effectively. The immutable String class exists because most of the time Strings actually are immutable. The distinction makes this explicit. The only time this becomes a problem is when people like you don't use a StringBuffer when they should.
BTW2. the whole point of my previous post is that creating and destroying small objects has little or no consequences in a generational garbage collector. Creation works like this: increment pointer with bytes needed, return pointer. Deallocation works like this: move everything that should survive the garbage collector in the youngest generation to the next generation (typically very few objects because the first generation is for shortlived objects), set heap pointer of first generation back to its initial value. This hard to grasp for C programmers because in C these are relatively expensive operations.
C++ is your hammer, good for you. If you'd spend as much time with Java as you apparently have with C++ you might have some different opinions about the whole thing. Three months to become an expert in anything is a very little time. I've been working with Java for nearly ten years and still I'm hardly an expert on memory management in Java. There's a lot to be learned on this subject.
The GC and swapping are two things. If your machine starts to swap, you are using a lot of memory. The problem is that it is not being garbage collected because you are using it. The key to fixing such issues is not to hope for the garbage collector to fix your memory issues but to identify what objects are kept in memory, which of them are using too much memory and why they aren't garbage collected. Don't blame the garbage collector for poor program design.
BTW. what I know of nio, it is clearly positioned as the solution for the type of app you were trying to create (IO intensive stuff & large memory buffers). And I agree, it's not a very pretty API and requires some study to get into. But it's understandable that you run into trouble trying to avoid using it while trying to implement something for which it was created in the first place.
I also agree that you were probably better off using something you know well rather than to dive into new technology that requires a lot of study to be similarly effective.
You sound like you are a decent programmer. However, the type of problem you describe is not exactly a standard thing: multithreaded, lots of disk IO, lots of memory used. Doing this right in Java (or any other environment) requires some knowledge about how things work. In your post you make it clear you do not have more than a rough understanding of how garbage collecting is implemented in Java or indeed the ins and outs of optimizing Java's behaviour in this respect. That's pretty essential stuff for this kind of thing.
I think the key problem with your Java implementation is not that it is written in Java but that it's design is based on some wrong assumptions about how things work in Java. For example IO quickly becomes a bottleneck, did you use the nio classes? Did you run a profiler to find out where the bottlenecks were? Maybe there's some synchronization issues? There could be a whole lot of things wrong. Optimization in Java is possible, just like in C. And just like in C it requires that you understand the technology.
I'm not suggesting you should do things in Java but merely that you should be a bit more careful to blame technology for things that may also be attributed to your lack of knowledge. It isn't Java that failed here, but you and indeed the end result is the same.
Slashdot Mirror
Gpl v3 makes one thing clear: it's all about ideology. If you don't subscribe to the ideology (e.g. because you run a for profit business instead of a commune) you should use a different license.
Actually the v3 is a bit confusing. Licenses don't need upgrades but clarifications if there is a legal error in them. v3 is different from v2 and not necessarily an improvement depending on your point of view. The GPL is generally understood to be v2 (and controversial enough in that version). v3 suggests it is the same thing with some minor clarifications. Clearly that is not the case, the changes are not minor and v3 might turn out be quite a bit more controversial than v2.
The nice thing about the feature matrix on that site is that it clearly illustrates the problem with many OSS cms systems: they're mostly low end systems with lots of important features missing. For example wordpress doesn't have most of the features. I use wordpress for my blog but I know the difference between that and a high end cms. Wordpress doesn't have versioning, it doesn't handle internationalization to well, it doesn't include workflows, it doesn't support custom forms, it doesn't support anything else then mysql. Just to mention a few of the big ones. Again, I actually like wordpress but I know it is not in the same league as most really good cms systems. But then it is really good for running a blog.
Of course there are some highend oss cms systems as well. I'm not criticizing them all. But most of the usual suspects that surface in this type of discussions (wordpress, cocoon, etc) are pretty low end systems: good for simple websites and nothing else. They can be adequate if you don't need the highend features but making a conscious decision about that should be part of the decision process. A common mistake is assuming you don't need the high end stuff and then doing a lot of custom development to keep the customer happy.
There's companies making some good money out of CMS system customization. Often they are a better option than inhouse development. If you're going to use OSS because of the cost aspect that's fine but as soon as bunch of your employees need to spend more than a few days of work to get the thing going you've probably made a mistake.
Sure it's not a bad idea from a technology perspective.
.Net client applications and in fact more or less told developers not to invest in .Net 1.x because 2.x was coming and beside vista would have avalon, eh sparkle.
Sadly, for Microsoft, it's their own fault that people are not 'getting' their new technology. So far they've done a very good job of getting the brand name out, only they failed to communicate what it is so people started comparing it to flash. And it's going to take some really good, consisting marketing to get rid of that image. I predict sparkle will quickly join the growing list of their failed marketing/technology concepts. By the time tools and platform have been deployed in sufficient numbers to make large scale developer adoption worthwhile, developers will have moved on. Vista (and the associated technology) won't be widely available until next year. Corporate adoption should pick up somewhere near the end of 2007 (and that's by MS own optimistic schedule, I suspect companies will be extremely reluctant in adopting vista). That's two years already. That's the earliest possible moment that a small market for sparkle apps might emerge. But then, why would application developers target such a small audience?
So that rules out sparkle for application development for the next few years. Besides, much corporate development is now browser based and thanks to Microsoft failing to do anything relevant on the browserside for a whopping six years now, that is now becoming a standards based arena. Internet explorer only products are really hard to market nowadays. ActiveX, another failed technology, is now regarded as insecure technology. Microsoft's non standard css and javascript 'features' are now used primarily to work around browser bugs.
The reality is that Microsoft is struggling to get the developers back on their vertical stack of technology. It's not working. They alienated their VB development community, failed to get widespead adoption of
Most encryption solutions suffer from obscurity and severe usability issues. Educating users who don't know nor care about encryption has always been the primary obstacle for getting people to use encryption (which is why most users have never ever heard of pgp and would be clueless if you send them your public key). So harddisk encryption works because it works transparently (if you set it up for your users), email encryption doesn't work because the user has to mess with keys, which he/she won't do. Encrypted usb sticks will work if you can guarantee they work everywhere and that no unencrypted sticks are used. Both of which are pretty much very hard to guarantee or enforce.
...). So precisely when security is most important, security measures force users to resort insecure means of getting to their data. Because you set up some unusable vpn, the user will just use the usb stick instead of spending five minutes of presentation time to get the vpn going. Much easier.
USB sticks are just plugged in and are pretty much guaranteed to be not encrypted. Mobile phones present similar difficulty. Most phones have poor customizability and security. In fact users are quite creative in finding workarounds for security obstacles. The primary use case for usb sticks is getting to your data outside the company when disconnected from the intranet/workstation for whatever reason (at home, at a customer, a conference,
So the solution is to reduce the need for transmitting data insecurely: make sure the user can get to his/her files securely in an easy fashion anywhere, anytime. The consequence of not doing so is the risk of users using hotmail, a usb stick or other insecure means to get the data where they need it (and they decide where that is, not you). Security can actually be counter productive if your users have to work around it and do so routinely.
Programmers write really shitty documentation (grammar is an issue, they don't understand the users, they make wrong assumptions about what should be documented and how) and are too expensive to let them do the job properly anyway. Like testing, writing end user documentation is best done by someone else. Let the programmer write code, designs and code comments.
More specifically, debian stable is (really) good for servers that don't need the latest and greatest. It sucks for workstations because you'll end up being one or two major versions behind for the most crucial desktop packages, including significant feature, stability and security improvements that go into these packages.
Debian unstable is good only for non production workstations. Specifically it doesn't have security updates; it will be in a more or less broken state most of the time (which may or may not affect you depending on which packages you use). Debian testing is only slightly better, you still don't get the security updates and buggyness still is an issue. Blindly updating a debian testing install is a ticket to disaster (been there, done that).
What's frustrating for new Debian users is that the Debian developer community is not really that interested in them. If you can get it to work good for you, if you can't RTFM. Also it is a safehaven for the ideological elements in the linux community. You know, the ones that insist on speaking of Gnu/linux. Dealing with the more extremist types in this community can be tedious. Lots of people use Debian for ideological reasons rather than pragmatic reasons. Recently the pragmatic part of the community made a mass defection to ubuntu (debian derived).
I'd recommend anyone looking for production use of debian in a desktop environment to only consider ubuntu. For small scale servers debian stable is a good option: you don't get the bloat of the big vendor stuff and it just works. For large scale servers, use something with support and reputation: red hat, suse are good options and all major vendors support them. Only use Debian on large scale production servers if you are willing, permitted and qualified to run it. Because if the shit hits the fan it will be you cleaning up the mess with noone committed to support your mess other than you.
Actually mysql works fine on windows. I've seen it being used in production and I've run it for about two years for testing purposes. Windows is quite a good choice for running mysql. You get a nice installer which makes configuration easy; there's several good mysql frontends (e.g. mysqladministrator) that make configuration easy and there's commercial support available if you need it.
....). Some of the desktop stuff actually works better on windows (e.g. firefox, eclipse).
In general, most oss stuff that makes linux popular runs on windows as well these days (quite often with very good commercial support available and user communities that dwarf their linux counterparts). Basically all of the commandline stuff is likely to already have at least an cygwin port. The more important packages generally have windows specific versions as well (e.g. apache, mysql, openoffice, firefox, python, perl, gaim, php
I'm a big OSS fan and I use windows almost exclusively. Aside from the OS and office (at work), most stuff I use is open source. I prefer linux for server environments, though, but performance or stability are not the reasons. Managability is the big reason for me.
Despite this I'm pragmatic enough to see that you don't want linux unless you have a capable sysadmin available to run it. Putting linux in an environment with a few windows wannabe sysadmins (i.e. most small companies) is just asking for trouble.
They are supporting it in the best way possible: they use an open, standard protocol that so far has been used and developed mostly in unix/linux environments. That's all the OSS community needs. What more could you ask?
Besides, there's no such thing as desktop linux. There are dozens of distributions, window managers, graphics toolkits that are used in basically any combination you can come up with. On top of that, there's different versions of all these components. Which ones of these combinations is desktop linux (answer likely to be highly subjective)? And will the answer to that question be the same in half a year?
A fourth important reason is being able to figure out who chnnged what when and why, sometimes years after the fact. This is something subversion allows you to do easily and it can be really valuable information when debugging some stuff written years ago. Subversion makes this very easy.
If mono becomes good enough, developers might start to target it when developing for windows. Right now that is not the case though: it's not good enough. Mono under windows sort of half works but the tooling, sdk, etc. all assume a unix infrastructure. You can of course develop for microsoft .Net but then you end up with their tooling as well which sort of automatically leads you away from cross platform stuff like mono.
Mono as a porting tool has no future IMHO. Mono as a cross platform development kit does have a future. Or at least the potential is there. I don't see much happening in the community to push it that way. Focus so far has been on the infrastructure level: getting the compiler & vm to work and reimplementing microsoft APIs. And yes there's even a windows build of mono available. Development tooling however is linux only, even though much of it is written on top of mono!. If writing a cross platform mono application on linux is already hard, why would the other way be any easier?
I believe mono as a cross platform development kit can happen but I don't see it happening right now. Development focus has been and continues to be linux only. Like it or not, windows has, by far, the largest share of the desktop market. Being able to support linux is nice but windows support is crucial for application developers (or at least the ones that depend on marketshare for income). Right now mono is a nice tool to develop linux gnome applications. If developing linux gnome applications is your ambition, go for it. If you need to look beyond linux gnome, you need something else for your applications.
I've traveled quite a bit and slept in some pretty shitty places. In the end the only thing that's relevant about a hotel room is whether the bed and shower are clean enough (some nasty surprises I've had in expensive hotels: somebody else's pubic hair in the bed, small bloodstains on the towels, a 'used' toilet, 'dubious' stains on the sheets).
I don't mind if the room is small, as long as my bag and I fit in to it and as long as it is clean. Hotels are mostly about providing a false sense of luxury at a low cost for people who don't get around very much. If you travel a lot, you're no longer impressed by it. Just like air travel had a reality check over the past few years, hotels will have a similar reality check. You can still fly business class if you want to but unless you are an overpaid executive, you'll probably fly economy class and pay for your drinks & meals nowadays (short flights anyway). Similarly, do you really need a minibar, a spacious lobby and an outrageous breakfast buffet? Sure it's nice to have but will you pay for it if the alternative is 50 dollars cheaper and gets you a good enough bed in a small but quiet room? Right now you don't have much choice.
When traveling privately, I always seem to find these inexpensive nice places and when traveling for work the room price is two or three times as high.
Energy is the key issue for this century. With plentiful, cheap energy available, mankind will be doing so many cool (or evil) things. Think hydrating the sahara desert, just because we can. Sure that will take huge amounts of energy but what if that was cheap? Currently, producing sweet water from see water is very expensive, mainly because of the energy cost. So is pumping it from the sea to the sahara. So are many other production processes. In many industrial processes, energy cost currently is the bottleneck. So take it away.
Currently, driven by rising oil prises, the increasing cost of oil production and the exponentially growing demand for energy, there are many research projects into alternative energy production methods, improving existing methods of producing energy and improving energy efficience on the user side. I expect 99% to lead nowhere and 1% to revolutionize the world. We've historically been very good at squashing technical issues on our path. Producing energy is just the latest hurdle.
It is my hope and expectation that we will tackle this problem during my lifetime. Energy is plentiful, we just need to learn how to tap into it more efficiently.
The platform is just something you use to run the software. Select the software first + the technical partner that will implement it for you. By far most of the cost of the whole thing will be in those two things. Hardware + os is peanuts compared to that. Then go with the platform recommended by your technical partner. If it happens to run on both windows and ibm, your ibm skills may be reusable (that's the real issue, isn't it?). That should be decided based on cost of ownership.
It's stuff like this that makes the big software corporations invest in patents. Companies like google and microsoft don't draw significant revenue from patents and actually invest heavily in research. But having patents guarantees that they won't end up sueing each other. It's a defensive thing and it has gotten way out of hand. I work for a large european company that files lots of patents (Nokia) and we are very much into this thing. European patent law doesn't allow many of the patents we file in the US. Just recently we got sued by this small company from the US. Filing patents is our primary defence against this. Our money comes from selling phones, not intelectual property licensing.
:-).
With the US patent law and office deliberately (this was/is lobbied for) weakened to the point where basically any brain fart may be patent pending, people are patenting everything they can think of with absolute disrespect to such outdated things as prior art, originality or even cleverness. It doesn't matter if an idea is stupid, based on existing ideas and stolen: a patent gives you the right to sue. The legal process is guaranteed to be lengthy, complicated and above all very expensive. The patent office rubberstamping anything they stumble upon ensures a steady stream of revenue for a growing group of companies who, in all honestly, have never lifted a finger to do anything remotely resembling research. Their revenues are based on bullshit portfolios of patents. Google is just the latest victim. Luckily they have the muscle to fight back. Many truely innovative companies don't.
The rats of the IPR industry are becoming an obstacle for innovation. Large corporations are now starting to feel this pain (e.g. Google, IBM, Nokia and Microsoft have all recently had to deal with lawsuits from insignificant IPR only corporations). The problem with IPR only companies is that you can't countersue. In other words, your patent portfolio is worthless if you are sued by one of those companies. It is my hope that these companies will get smart and start lobbying against software patents instead of in favour like they have done in the past. Just today I joked to a colleague that Nokia should quit selling phones and focus on the Nokia Research Center I work for
The real lesson is of course that once again mr buffer overflow strikes (don't implement anything in C if it needs to be secure). This time it's on windows. On windows it is bad because a lot of people use windows so any bug presents hackers with a huge opportunity to affect millions. On linux, buffer overflows occur just as often (or more often according to some sources) but are much harder to exploit because of the diversity in linux installations. Essentially it is pretty hard to find a meaningful number of linux computers with the same unpatched bufferoverflows, finding linux computers with unpatched bufferoverflows in general is easy. Linux offers great security through obscurity. The linux desktop (if there even is such a thing) is so rare and likely to be different from most other linux desktops that it is unlikely to ever be the victim of a coordinated effort to exploit a buffer overflow. It would basically require a large amount of linux users running the same version of the same software compiled with the same compiler for the same plaform. The total amount of linux desktop users of course is hardly interesting to begin with.
.. And not the other way around. I'm a developer, I tend to be understanding of sysadmins: as long as they give me local admin rights to my machine. Especially in larger organizations, sysadmins can be real pain. Often they don't know (nor care) who you are. Getting anything done requires getting a helpdesk ticket, which will end up on some desk. Then maybe three days later some guy picks it up. That just sucks if you are trying to get your job done.
At my current job one of the first things I did was request local admin rights. I think the guy must have understood that I'd be inserting a lot of helpdesk tickets in his queue if they refused the request. In any case, I've been pretty happy since and haven't had to bother them since.
Eight years ago I was living in sweden (I'm dutch) and there was this cool new thing called streaming video. You could watch for example the dutch news in 50kbit/s. Fast forward eight years. I now live in Finland. I have a nice broadband connection and aside from the news (now in ok-ish 500 kbit/s) there's still not that much interesting to see on the net. There's lots of crappy stuff out there but mostly you still can't (legally) watch a pay per view movie, series, etc. The bandwidth is there, the technology is there but the content providers aren't.
Sure there are lots of local cable operators and telcos that offer you a very limited choice in video channels and pay per view stuff but none has gone online and offered their services to whomever has the bandwidth. I'd probably pay for 20mbps instead of the 1mbps I currently have if that would get me high quality content at a reasonable price level. Right now it's just not there.
I can get a premium selection of IMHO shitty digital channels (discovery*, CNN, etc.) for 25 euro per month or I can put a satelite on my roof and receive hundreds of channels, including most channels from my home country for about 10 euros/month. I'd gladly pay 10 euros per month for the same content over an internet connection (provided the quality of service is good enough).
There were always enough loopholes in the law before, during and after the patriot act for the various agencies to do whatever they wanted. The patriot act was all about publicity. Bush had to show he was doing something. It worked, it got him reelected.
I admire the strategy. It's a brilliant example of thinking out of the box. It pissed everybody off and that's exactly what was needed to communicate the illusion of leadership.
It also did a lot of dammage to the legal system, foreign relations and the actual ability to fight terrorism effectiveley. Really, pissing of allies is not a good idea in any kind of war and Bush has done his best to do so even with his closest allies (e.g. the UK, Poland, Italy, Spain).
That's why the patriot act has to go now. But that's not part of the strategy. Exit strategies are always the weak factor in the Bush administration. Whether you look at iraq, the economy (budget deficit, pensions), environment etc. Each time the strategy is accepting long term dammage in exchange for short term results. The average voter has an attention span of a gold fish so the future is irrelevant. It's a very cynical form of opportunism. Bush is an idiot, but his cheerleaders aren't and they are pushing this agenda with full knowledge of all its long term effects. They just don't care. The only problem now is that some of the long term effects are showing up a few years ahead of schedule. The iraq stategy is back firing, the economy continues to be weak (despite all the spin put on the statistics), allies are complaining loudly and even the environment is back on the agenda.
Bush is history though. He's become a liability for the upcoming election which will destroy the republican party majority and what we are seeing now is dammage control. It might even work! Again the strategy is brilliant: get all the negative stuff in the paper now so people will have forgotten about it when the elections dominate the frontpages. Cynical, effective and brilliant.
The following presidential election he'll have to go anyway and by then his successor will do his/her best to disassociate himself from the long list of mistakes of the previous administration. That's three long years from now, plenty of time for competent campaign strategists to rewrite history. Bush has simply been ejected from the republican party's strategy. And that's the best news I've heard in years.
Yes, the process makes use of the fact that internal combustion is a particularly wasteful process that transforms most of its energy straight into heat instead of movement (ultimately 100% is transformed into heat of course). Apparently the efficiency gains of injecting hydrogen into an internal combustion engine are more than enough to compensate for the energy lost in generating the hydrogen. Amongst others. the fuel burns more completely (instead of unburned particles being ejected straight into the atmosphere).
Yes, my standard adsl line can do 8 mbps now and 20mbit if I upgrade to sdsl. A standard harddisk would currently do 400 MB. Using mpeg4 (crappy mpeg4 = 512 mbit/s, dvd equivalent mpeg4=2mbit/s, hd mpeg4=10mbit/s) that's good for a few hundred hours of dvd quality video. As you note, mpeg4 and similar codecs scale up nicely and full HD content can be stored and streamed at about 10 mbit per second. If you insist on storing that level of quality, that is perfectly feasible as well on todays harddisks. You basically trade space for quality. Most people I know don't own more than 100 dvds (about 200 hours).
So lets say 300 hours HD quality is 10000 GBit. Divide that by 8 (bit != byte) and you have about 1.3 TByte (rounding up here for the sake of the argument). That's a lot of storage but definately in reach for consumers these days. But then if you can own 300 HD quality movies today, buying the necessary storage to store that won't be an issue. Of course we are years away from being able to actually go out and buy 300 different movies in HD format and by that time 1-2TB of storage will be pretty common in pcs.
But then storing video locally isn't even necessary when you can stream it any time any place any where.
For me digital content distributed any other way then through a network is a thing of the past. My standard dsl connection is perfectly capable of streaming HD video content. A single consumer grade harddisk is capable of storing hundreds of hours of HD video. But why store stuff clientside at all? Just stream the content to my tv when I want to watch it.
I have some experience coordinating releases of a software product. A key thing I have come to realize is that developers don't understand that last minute patches cause more problems than they solve. Inevitably something they regard as important creeps in and that's when you need to just say no. Convince me it's critical (stuff breaks down visibly, data is lost, etc.) or wait until the next release. I've seen this go wrong more than once. Some dork commits something 30 minutes before the release and a week later we're handing out patches for bugs that fix introduced. Unlike OSS, delays are usually hard to negotiate in a commercial setting
With a product as complex as a kernel you need lots of time to properly test and integrate stuff. A kernel release needs to be stable & reliable. Last minute changes with unkown impact are unacceptable unless they fix something that absolutely needs to be fixed.
The git scm tool that linus uses actually supports this development style very well. Developers develop and send in patches to a central repository. Linus pulls the important patches and patches his private repository for a few weeks and then locks it down for testing. That's why he can afford to tell developers to wait or adjust to his schedule.
In this respect he is quite ahead of the clearcase/cvs and svn using masses. These tools do not support this kind of development very well. The mental model of the developers is still that they need to get their stuff in the trunk asap. With git the model is get your patch out, have it tested, optimized and when it is mature and ready Linus will merge it when this fits his release schedule. For complicated changes this process should be slow or otherwise Linus ends up doing the work that should have been done before the merge.
This model is way better than freeze trunk, tell everybody to not do anything for a few months and then release.
Yes it's different than what you are used to and no you can't do most of the things you cite (a few you can actually). Most Java programmers don't see that as a problem. Programming Java simply works differently than programming C. If you apply your C skills to Java or your Java skills to C, you are very likely to write crappy software. Both languages require different approaches for solving the same problems.
BTW. the StringBuffer class solves your problem quite effectively. The immutable String class exists because most of the time Strings actually are immutable. The distinction makes this explicit. The only time this becomes a problem is when people like you don't use a StringBuffer when they should.
BTW2. the whole point of my previous post is that creating and destroying small objects has little or no consequences in a generational garbage collector. Creation works like this: increment pointer with bytes needed, return pointer. Deallocation works like this: move everything that should survive the garbage collector in the youngest generation to the next generation (typically very few objects because the first generation is for shortlived objects), set heap pointer of first generation back to its initial value. This hard to grasp for C programmers because in C these are relatively expensive operations.
C++ is your hammer, good for you. If you'd spend as much time with Java as you apparently have with C++ you might have some different opinions about the whole thing. Three months to become an expert in anything is a very little time. I've been working with Java for nearly ten years and still I'm hardly an expert on memory management in Java. There's a lot to be learned on this subject.
The GC and swapping are two things. If your machine starts to swap, you are using a lot of memory. The problem is that it is not being garbage collected because you are using it. The key to fixing such issues is not to hope for the garbage collector to fix your memory issues but to identify what objects are kept in memory, which of them are using too much memory and why they aren't garbage collected. Don't blame the garbage collector for poor program design.
BTW. what I know of nio, it is clearly positioned as the solution for the type of app you were trying to create (IO intensive stuff & large memory buffers). And I agree, it's not a very pretty API and requires some study to get into. But it's understandable that you run into trouble trying to avoid using it while trying to implement something for which it was created in the first place.
I also agree that you were probably better off using something you know well rather than to dive into new technology that requires a lot of study to be similarly effective.
You sound like you are a decent programmer. However, the type of problem you describe is not exactly a standard thing: multithreaded, lots of disk IO, lots of memory used. Doing this right in Java (or any other environment) requires some knowledge about how things work. In your post you make it clear you do not have more than a rough understanding of how garbage collecting is implemented in Java or indeed the ins and outs of optimizing Java's behaviour in this respect. That's pretty essential stuff for this kind of thing.
I think the key problem with your Java implementation is not that it is written in Java but that it's design is based on some wrong assumptions about how things work in Java. For example IO quickly becomes a bottleneck, did you use the nio classes? Did you run a profiler to find out where the bottlenecks were? Maybe there's some synchronization issues? There could be a whole lot of things wrong. Optimization in Java is possible, just like in C. And just like in C it requires that you understand the technology.
I'm not suggesting you should do things in Java but merely that you should be a bit more careful to blame technology for things that may also be attributed to your lack of knowledge. It isn't Java that failed here, but you and indeed the end result is the same.