In short, memory allocation in Java is faster (measured in cpu cycles used) and it can use both stack and heap based memory allocation (unlike the urban myth that Java can't do that). Additionally, for short lived objects, garbage collection is essentially free (unlike calling free() in C++). Of course you can do clever stuff in C like not actually using malloc and free but most programmers default to not doing except for some very specific cases. In other words, most of the time Java is actually faster for both allocation and deallocation of memory.
People like you run into trouble when they manually call the garbage collector (bad idea, can cause severe performance issues) or when they misconfigure the garbage collector (e.g. if you are running a server with multiple cpus and multiple gigabytes of memory). Also a big issue is C programmers trying to program Java like it is C and making wrong assumptions about the cost of certain code and the impact of certain optimizations (e.g. pooling is actually bad for performance in some cases).
The only real problem that Java has with respect to memory management is that java programmers tend to use lots of memory when writing their software. You don't have to do that but using the default APIs and recommended practices in e.g. the java tutorial and many books on this matter you will probably end up using substantial amounts of memory. Many Java programs continually create and destroy large amounts of small objects. If you'd do that in C/C++ you would really notice this. In Java you hardly notice this at all because it allocates and deallocates in a much smarter way.
I don't know what 'personal tests' you have been performing. Up front I'd say you may have been measuring the wrong things the wrong way and have been drawing the wrong conclusions based on what your results. The JVM is a highly complex piece of software and very difficult to benchmark properly. Doing so requires that you know
I think your reply illustrates my point quite effectively. Nothing you cite is actually worth boasting about but you do. That's the point. You don't like teenagers (you have my symphathy), so you think google's summer of code actually made a difference for end users (naive) and you managed to find two cases where MS actually copied some features from software packages that also run on linux (but have the majority of their users on windows). Good for you.
You think those are major features, I think that's unimportant entry level stuff. If even that wouldn't work right you'd have a pretty shitty tool. The problem with linux desktop software is that 1) their developers are biased to developers. Most of them don't understand the needs of users, especially not when these users are 16 year old highschool girls. 2) their developers have rather strange ideas (for a windows user) about how user interfaces should function and what features are important.
Sure you can do IM on linux. You'll be able to send text to just about any IM network invented, ever. You'll be able to do so from dozens of different clients. And they all look like rather conservative business tools. As does most of the linux desktop.
What's lacking is a forward thinking attitude. Personal communication is a hot thing (and not new at all) and all the linux community does is whine and catch up with yesterdays software. MSN users are used to msn which has a featureset that includes text messaging and a whole lot else. The whole lot else part is actually pretty important to some users. The whole lot else part implemented pretty poorly in msn alternatives (if at all), including miranda-im, gaim, trillian, kopete and other clients I've tried over the years (miranda im is my default client now).
Now what makes me angry is not the fact that this stuff is lacking (I don't care) but that this thread is full of people who are trying to argue away the need for improvement. IMHO this attitude and not any technical limitation is what has been, and will continue to keep linux off the desktop of ordinary users.
What's worrying is not that gaim is such a primitive tool but that its developers are pretty pleased with it. Where's the ambition to implement some cool stuff? Where's the ambition to go beyond what microsoft is doing? This total lack of ambition to improve anything on the linux desktop is what's keeping it back, not the competition (or lack thereoff) from microsoft.
Just look what apple has done in just a few years: they constantly poor out new exciting stuff with a fraction of the number of developers working full time on Gnome and KDE. They too have to deal with Microsoft. But at the end of the day Microsoft looks at apple and not at linux to see what features to clone.
You can't prevent bad/malicious programming of course but you can prevent the vast majority of bugs that are typically exploited by hackers, like buffer overflows or dangling pointers. Java is immune to both these issues. Therefore, Java is a much more secure environment to program in and therefore the use of C/C++ is nearly non existent in the web application domain.
Infrastructure is a different matter. That too will become the domain of java like languages in the future but for the moment we will need to continue to patch the endless stream of buffer overflow issues in such fine products as apache, iis, bind, openssh, etc. These packages have two things in common: 1) they are written in c/c++ and 2) despite years of security audits and bug fixing, new security issues directly related to C's inherent insecureness continue to be found in them on a regular basis.
True, Java depends on native stuff. In fact most known java exploits are indirectly exploits of bugs in this native stuff. The rest consists of genuine design flaws in the program at hand. However, exploiting bugs in native code from Java is actually quite hard since it involves making a lot of assumptions to the run-time memory usage and garbage collecting. Consequently, there have been relatively few incidents of Java bugs being actually exploited.
In short, if security is important to you, don't even think about using C. Even if you (the programmer) do your work properly, there is no guarantee the developer of the libraries you depend on did. There will no doubt be some in this thread to point out that if performance is important, you should choose C. IMHO these people overrate performance and underrate other important quality attributes like maintainability, security, flexibility, reusability. But who am I to judge these folks:-). Besides, fixing performance issues in Java is not that hard, if you know what you are doing. But then if you didn't, you shouldn't be trusted with C either.
You rightly observe that piracy exists. You imply by your style and wording that this is a bad thing and that the world would be better off if it didn't.
Take away the moralism and the wishful thinking you can deduce the following: 1) piracy apparently exists 2) it is apparently extremely hard to fight legally 3) and therefore it will continue to exist until either 1 or 2 change.
We've already seen over the past few years that fact 1 is unlikely to change by itself (people like free, easy to get goodies) so that leaves us fact 2 to improve on.
In a sense fixing fact 2 is what is happening in the US and a few other countries. However, so far, not to an extent that it becomes measurably effective (instead of obviously counterproductive). The rights of people and corporations are being constrained severely but the effect is 0. These measures have all sorts of negative sideeffects such as companies (even unrelated to p2p or piracy) taking their business elsewhere or going out of business (jobs lost, economy suffers), young people's lives being destroyed and millions of $ being pumped into the legal system instead of being invested more wisely.
Conclusion: moraliststic pricks obsessed with piracy and out of touch with reality are wreaking havoc in our legal and economic systems. I personally think that is a bad thing, much worse than some highschool kids downloading stuff.
There's clearly an untapped reserve of users who need cheap, easy to use design tools. Adobe & macromedia are at the very high end of the market. Their tools are powerful, expensive and intimidating. Sure they have some entry level versions of some tools but these are individual tools, not integrated suits of tools.
Microsoft has cleverly spotted this opportunity.
Also, Microsoft already has much of the necessary technology in various office addons that most people don't even know about (e.g. MS Publisher, photo editor), various stuff from their research department (mainly photo editing), and other stuff like their movie editor. And finally with some acquired components you can build a pretty interesting suite that is not so capable as the high end offerings from Adobe and Macromedia but cheap and usable. That's a good position to start from and over time they'll be able to add features to make the product more interesting.
Ideal for home users that want to edit their holiday pics, ideal for small businesses wanting to make a brochure, etc. In fact good enough for the majority of people who own a photoshop license, a dreamweaver license or an illustrator license. It's amazing how many people buy stuff they don't need. At the office we have a few photoshop licenses. The most advanced thing that ever happens there is to crop a few photos and create some transparent gifs, that sort of stuff. All the artwork we use in our website is actually delivered by professional design studios. Only recently the use of the gimp was promoted for this kind of stuff.
The world is full of users for who photoshop (or it's lightweight derivatives) is overkill or who do not need the full capabilities of illustrator or who do not need to develop complex webpages in inDesign or dreamweaver and who generally feel intimidated by all of the previous tools. Yet these people want to create stuff. They don't want to shop for this tool or that tool. Instead they want the tools on their PC when they buy them. People are lazy, most of them never buy software after their new PC is delivered.
And who happens to have a big influence on what is preinstalled? Right, Microsoft. Imagine how many people will toggle that nice MS Design Studio checkbox on the dell site (hell, why not it's only XX $ and I'll be able to do foo with it). Imagine how many companies will be tempted to spend a few dollars per desktop for this. It's easy money for MS. Even if it's only 1 percent of their users, that still is a huge amount of money.
You could argue that they are abusing their market position. You could also argue that other companies have simply failed to fill this gap in the market for years. Adobe only recently started to make consumer versions of their tools. You need to buy them individually and the full suit of tools is for high end users with big budget only.
Some elaboration: 1.1) Also clean out the program directory. Make sure to backup any search plugins and plugin dlls because you may be able to reuse them. 2.1) When you launch move the plugin dls back to the plugin directory, don't overwrite existing files (probably newer) 2.2) Copy the searchplugins to the searchplugins dir 2.3) Copy the bookmarks, cookies and passwords from your old profile to the newly created one 3) this step is not possible because you have a new profile: reinstall all of the extensions you want to use
Im not going to read the article but the reasons stated in the summary suggests a strong (and maybe well funded) bias. In short, the summary is basically bullshit. The quoted material on the ms blog is suspicious and the scientific study might actually be quite good (I wouldnt criticize it without reading it first).
Security is not something you just switch on in a project. You design your project from the ground up to have security features. Both Java and.Net come with very similar security features. Both have finegrained role based security features. Id say Java is somewhat more flexible by providing an extensible model so that you may provide your own protocol implementations. For example, I used an oss pgp implementation recently that plugs into the default Java security api..Net on the other hand has some nice language features like attributes. Java has null securitymanagers;.net has unmanaged code.
Javas security features are designed through the JCP process in which a broad range of industries and individual experts have been and continue to be involved. Indeed some of the older security features come from the earlier JDK versions developed by SUN. Overall I trust this process more than I trust the microsoft process which when it comes to security has received a lot of criticism over the past few years.
I can see your problem. High school kids are not computer science students so you need something simple. You want to teach them something useful that will help (and motivate) them to possibly consider taking a bachelor/master in an IT related field.
I was about to recommend Java. But I think that might be too abstract for high school kids. You'd probably end up scaring most of them with it (and I am a Java programmer). The nice thing about VB was that it is simple, gets results quickly and that there used to be a market for VB programmers. This market (and the market for fat clients) is disappearing rapidly.
So you need a replacement that is easy to learn for not particularly talented high school students, gets results fast and has some reasonable demand in the job market. That excludes legacy stuff like pascal, delphi, vb; obscure scripting languages such as perl, ruby.
Php is popular but is a bit the C++ of scripting languages: you can do lots with it and you'll likely shoot yourself in the foot. In other words it's not the ideal language for teaching. So I point you to similar languages like jsp and asp.net. You can do similar stuff with those technologies. In the case of jsps there is java behind it and lots of useful taglibs to do difficult stuff. You get results quick; web pages are something every high school kid understands. There's definately market demand for jsp programmers. Asp has similar advantages and may be a logical successor to your VB based course. Tools might be a final consideration. Microsoft can be expensive but they are known to make deals with educational institutions. Java/jsp tools are available for free but come with requirements that might exceed what you have in the school computer rooms.
You can actually disable the bloat in xp. I installed windows xp on a 1997 pentium II 233mhz with 64 MB once. Both cpu and memory were way below the official required spec. And of course the out of the box experience with everything on was nothing to write home about but it worked. If you strip it you are left with an improved version of windows 2000. The kernel is a mere minor version increment over windows 2000. The rest is just services which, mostly, you probably want turned on if your machine has enough memory. Since memory is dirt cheap, do youself a favour and quit trying to shave kbytes of the memory usage and install 512MB (or more).
I agree some services are probably not very useful and indeed ms windows has not been designed for computers that already shipped with an OS in the last century. Can't really blame them because there is no market for such OSes.
Now (i'll take the bait) the Java language is another thing. At a mere 15.54MB download (just checked), the jre packs a whole lot of functionality. Of course the development kit is somewhat bigger at 56.71 MB but still pretty ok if you consider that A) you don't need it unless you do development and B) it includes examples, the full jre, tools and source code for the libraries all in one package. And it will work on your favourite last century OS win2k of course. Hardly bloated in a time where broadband is cheap and widely available and pcs ship with 120GB or more of diskspace. I'd certainly would not want SUN to remove features to please a few whiners like you.
Anyway the idea of pcs is that they are cheap. It will run the software it came with just fine. Maybe if you spent some money it will live through a few software upgrades (say it came with windows me, you upgraded it to win2k: good for you). After that, be happy the thing still works and spend the money on a new PC if you want the latest and greatest. A 1000$ should keep you happy for another few years.
Agree. It would be quite ironic that one of the most violent games of this moment would be banned from the shelves because of some sex feature that is not even enabled by default. The mere suggestion of sex (it's not more than that) is enough to provoke this kind of reaction, the simulation of city wide riots, gang wars and drug violence is not.
It's also ironic that the same people who freak out over accidental nipples on tv look the other way when it comes to guns. It's ok and considered normal to handle a gun at fifteen but you can't legally have sex until three years later. A beer takes another five years. Someone not to be trusted with alcohol can safely handle a gun according the US law. That's just fucked up. And speaking of swearing, it's ok to put a bullet through someones head on prime time on tv. But if the guy on tv says "fuck, that hurts" you hear a little beep. IMHO the visual depiction of someone being shot through the head is probably a bit more shocking to a minor than someone using the F word.
The people who rate movies, games, etc. and the people who inspired the whole notion of rating have got their priorities the wrong way around.
BTW. GTA is great fun:-). However, I can imagine parents being a bit concerned about the violent nature and the reference to whores, drugs, criminality, etc. You probably don't want your toddler playing this game. However I have no respect for the people who think that this is ok and yet somehow the sex thingy is not.
depends on your definition of art (there appears to be authorative definition of the word art anyway). I'm not really interested in either the definition or the answer to the question.
But then the question is typically asked by programmers looking for a justification of their work. Hint your not an artist but an engineer. Others will judge by your engineering qualities, not by your artistic skills. If the code is beautiful crap it's crap to the outside world. It might be a work of art to you but nobody will care until you fix it.
I agree, the current trend is very much in contradiction with closed model the irrelevant publishers make their money from. I say irrelevant because there is a disconnect between scientific content production (by volunteer scientists), scientific content reviewing (by volunteer scientists), and scientific content consumption (by basically anybody who cares) on one side and the publishers on the other side. They used to have a significant role in replicating and distributing content. Basically the internet has obsoleted them so why exactly do we keep giving them money from precious research grants?
Different discussion. However back on topic. Publishers are unlikely to protest against authors putting pdfs of their articles online. Incompetence is of course a big reason (no doubt inspired by indifference). They simply have no clue what is going online. They sincerely believe they have an important scientific role. In reality they just put ink on paper (for a ridiculous price). The entire scientific process is external to them (writing & peer review).
It's just a matter of time because the scientific community moves away from the traditional publishing model. Already google is important for article citations. If it is not online, it is less likely to be read. Personally I strongly disliked having to deal with libraries & librarians when I was still in university. The whole process is slow, tedious and time consuming (usually weeks because a photocopy had to be snailmailed from some distant other library). If I can't find the pdf online I am unlikely to walk to the library unless I really want to read the article (for example moore's orinal article on moore's law, interesting read).
The google factor is undeniable. If you are not online nobody reads your articles these days.
The question is not whether google is good enough but wether the commercial offerings are good enough.
As others point out google scholar is free. Generally commercial solutions aren't and work on subscription basis.
Furthermore google scholar works by basically more or less the same strategies as regular google. Put some search terms in the box and relevant search results will surface. This is a different strategy than the traditional solutions which index many different kinds of metadata and allow for elaborate searches based on that metadata. Both strategies have their place but eventually price and convenience will determine who dominates the market. If simple queries are your thing, google scholar is the preferred search engine. If you are a fussy librarian, you probably need something more sophisticated.
I'm a researcher who is not associated with a research institute and thus has no access to academic search engines, online subscriptions, etc. I do have access to google scholar. If your article shows up there with a download link for the pdf I can read it. Otherwise I have to make an effort to read your article. The way scientific publications work has changed over the past few years. Journal publications give you status, google gives you exposure. Many researchers end up reading my articles after doing a google query, not after consulting a table of contents of some journal. Google is convenient that's why it works so well.
I have a number of different use cases that are typical for me: - get some useful references on a topic - look up the correct reference for something you have read - find stuff written someone you've read other stuff from - find out who is citing you
All these things google scholar does well. If you are a researcher it is in your interest to make sure google returns relevant search results if people look for your work stuff that is related to your work. Putting your articles on a website is all you need to do.
.. what would happen if Apple decided to just offer the OS without the hardware? MS is in an enviable position of having a monopoly on x86 pc operating systems. There is some competition but none of it is taken seriously at the moment (except for servers). Even cost conscious companies choose windows over linux for their desktops.
Mac OS X x86 fixes this.
It's got a unix touch yet it is user friendly (unlike almost any other flavor of unix). It performs well and doesn't suffer from any of the trademark Microsoft deficiencies (security fixes every week, poor usability, an indifferent software vendor, the occasional BSOD & a hefty pricetag). Users apparently seem to like it and there's a decent selection of OSS and commercial desktop apps (including MS office!).
Apple should be able to get 5% marketshare of the PC OS market within a year or so. I expect that there is a turning point where the marketshare will grow rapidly at the cost of windows. For example, a deal with Dell might be such a turningpoint. That means a steady flow of revenue that outperforms anything that can be realized through Apple hardware sales. Most of it is profits because they already did the hard work of writing & porting the software.
I don't use linux. Obviously desktop linux is not a priority for IDE developers. SWT has basically sucked big time on linux and nobody seems to care. In the absense of a unified, consistent native look and feel, the swing L&F is probably not so bad under linux.
Eclipse fanboys assume eclipse is faster because of SWT. And that is my whole point. On windows this performance advantage does not really exists and eclipse is noticably slower than the swing based netbeans. Apparently other factors than GUI toolkit are an issue here.
I use eclipse every day: it is slow. IBM was mistaken in thinking that SWT was a solution for performance issues in IDEs. I work with eclipse on a daily basis. I recently replaced 3.0.2 with 3.1M7. I've given up on the myeclipse J2EE plugins because these bring my system down to crawl. Netbeans offers similar features to the eclipse + myeclipse combo and is noticably faster on the same projects (basically the only thing eclipse does well IMHO is editing java code). By faster I mean that the dialogs are more responsive, I spend much less time waiting for the IDE to finish validating, manipulating large project trees in the project explorer is fast and responsive.
The rendering myth is bullshit both swt and swing use native, hardware accelerated routines to do the rendering. SWT uses native gui libraries to do this, swing uses java2d which in turn uses either directx or opengl depending on what os/vm combination you use. Rendering stuff on the screen is not an issue with either. SWT basically suffers from the same performance bottleneck as Swing: the event queue and rendering logic share the same thread. This means that lengthy event handling code blocks the UI. The solution is using a worker thread to off load lengthy operations. Using worker threads everywhere was the big improvement in netbeans 4.0 and is the reason why you are now seeing reports everywhere on netbeans outperforming eclipse. Good swing applications use worker threads. Many swing applications are coded by people who don't understand threading though. The same is true for swt. If you understand how to use threading you can build nice responsive UIs with both.
The eclipse UI blocks frequently. Opening/closing a large project tree is a good example. In netbeans there's no delay no matter how big your project is, in eclipse there is a noticable half second freeze even on small projects. Eclipse frequently freezes for a few seconds.
3.1 M7 is actually quite an improvement performance wise but they've not catched up with netbeans yet and will have to do much more to compete effectively. If you read the changelogs you'll see they are full of performance fixes. Apparently there are lots of performance issues to fix.
The reason I continue to use eclipse rather than netbeans is the Java editor. It is simply much better & smarter than the netbeans code editor (though slightly less responsive). I don't care for project wizards, I just want a smart code editor that helps me rapidly poor out code. Refactoring and code completions are where eclipse really shines. The debugger is nice too and quite handy if you install the right plugin for integrating with tomcat.
Agreed, for that kind of money you basically already have the best solution. Assuming your goal is to cut on the 15000 dollars and not push some idealist OSS agenda, you are not going to make any substantial cuts this way. Plus, your 'clients' (the students & staff) will probably complain loudly if you take away the software packages they are used to. At 15000$ the cost argument is ridiculous so you'll have a real hard time explaining why they have to use open office instead of ms office. Unless you remove IE from the system (which boils down to replacing the OS), people are going to click that blue IE icon.
What you'll end up with is a complicated mix of operating systems, offices suits and browsers that you will need to support. You will increase cost rather than cut cost. Forget about eliminating MS from your systems, you'll end up doing all the work you do now + the additional work for maintaining your home built linux enterprise management kit (I'm assuming you are not interested in commercial linux support with per seat licensing).
This has been posted in the last thread on svn and I don't agree. I've used subversion for more than a year now. I find it to a be a very reliable and easy way to put files under version control.
The reason cvs fanboys love having textfiles around is that, well, you really need them in the not so unlikely case that cvs messes up. One of the many things that svn fixes is atomic commits. In svn a commit either fully succeeds or fails. In cvs on the other hand it may actually fail halfway and leave the repository in an inconsistent state. When that happens, ascii files on disk are quite nice to have.
Svn fixes this by using a database and by not commiting changes to the database until everything is ok (not rocket science but nice to have when you are working with your most valuable assets: source code). In addition you can of course make incremental backups (on the fly) of any svn repository using svndump (which outputs a nice ascii representation of all commits in the order they occured). If you are really paranoid, you can do this every ten minutes (because it is incremental) and backup the db files every night.
If the worst happens (diskcrash?), you have the svndumpfiles, database backups and your user's local work directories to work with. That should provide everything you need to recover all data. If not, it is not a technology problem but a matter of backup discipline.
Now for all cvs users, migrating to subversion is as simple as creating a svndump file with cvs2svn and loading this dumpfile with svnload. Versionhistory, tags, branches etc. is migrated completely.
I mean broken as in from that point apt-get throws errors about various executables and libraries not being found on any subsequent attempt to install something (even the most trivial packages). In my book that is a serious situation that should not occur no matter how broken the package is. As for debian documentation, I've been conditioned over the years to expect that linux documentation (specifically debian documentation) is usually incomplete, out of date and quite often incorrect and internally inconsistent. Don't blame me for not rtfm'ing. In this specific case I was following the steps outlined in some howto on getting a debian desktop working. Clearly the howto was out of date and as I experienced incomplete and in some places incorrect. It fully met my expectations.
The problem with your attitude (which is illustrative of how the debian community deals with end users) is that it argues away the problem. The problem is that apt-get can break down and that you need expert help to fix it. The problem is not end users ignoring available documentation (this is actually one of the few predictable things in software engineering). The whole point of apt-get is that it shouldn't break down, that you shouldn't need to fix it, that it fails gracefully in case of problems and that you can install stuff without reading piles of installation howtos.
The problem with debian testing is that it is in a more or less permanent state of being broken somewhere (that's why it is called testing and that's why it is not suitable for end users). Install the wrong package and you end up with a broken system that can only be fixed in a non trivial way. Complex packages like X, gnome and kde are always a challenge to get working on debian because of this. Sometimes it will work sometimes it won't. In fact, no debian testing install I have used has lasted more than a few days because of this. Invariably I ended up apt-getting a package that apparently I shouldn't have touched. Once things break down it can get ugly quickly.
There's nothing wrong with the philosophy in theory. There's a lot wrong with the philoshophy in practice. If you install debian stable desktop apps you are running software with many bugs (including security bugs) that are not being patched by the original developers because they've moved on to versions that probably include a lot of relevant fixes & features. In addition you are missing out on four years of significant feature development (the stuff in stable was obsolete when woody was released). Four years is a long time for desktop operating systems (cough, microsoft are you listening?). When's the last time you saw a KDE 2.x update? A Mozilla 1.0 update? Nobody is maintaining this stuff anymore, except for the debian guys.
IMHO the KDE guys are much more qualified to fix KDE than the debian guys. I can understand that you might want to wait a few months before incorporating a KDE release in a distribution. But the debian guys are behind a lot of versions and they're not even trying to keep up. And this is the case with most major packages in Debian. They're shipping stuff that the original developers no longer care to maintain. Really when's the last time you installed a mozzilla 1.0 patch or a KDE 2.x security update?
When you are running a server this doesn't really matter much because on a server you don't constantly install new software but instead you focus on a handful of server applications (e.g. apache and mysql). You can afford to compile the latest versions of those applications yourself if you need to. This is what debian is good at: laying a good foundation for running a handful of customized server applications that really matter to you. I'd pick debian if I needed to run a stable linux server.
However, this philosohy doesn't scale well to the desktop. Almost all debian desktop users run testing or a debian based distro derived from testing. Testing is not that good. On all occasions I tried it I managed to freak out apt-get in no time with a very small number of apt-get installs, updates and upgrades. Last time (two weeks ago) apt-get install kdebase did the trick. Poof errors all over the place. Probably it was fixable but it shouldn't need fixing in the first place. Debian users recommend using testing for desktops, I'd recommend using a finished and tested product instead. There are plenty of those around. Some are even derived from debian testing. Ubuntu is currently doing what the debian community is currently not doing: supporting end users.
Interestingly the debate shows that maybe the deb package format is not so perfect. Wasn't the package format intended to prevent this kind of compatibility problems? For years the debian people have been claiming the superiority of the.deb format over rpm. Now poof, compatibility problems between debian and ubuntu. What's going on here?
Not yet. The problem with j2me is that there are so many implementations (and some of them really suck) of it. Some have JIT, some don't. There are a lot of hardware/software combinations. And that makes testing really hard. Of course you have the same problem if you move to another language. Because of that, there is not a lot to choose from. Brew and J2ME are basically it. Brew is optimized for gaming and J2ME targets a wider variety of software applications. Brew is a traditional, proprietary solution whereas J2ME is much more open with free development kits, documentation, etc. As Carmack notes, it is much easier to get started with it.
An additional problem is that the core J2ME specs don't cover much functionality. All the interesting stuff is in optional modules which may or may not be implemented on a J2ME phone. There's a whole range of J2ME specifications that may or may not be implemented.
John Carmack reasons very simple from a game developer point of view. Basically anything that gets in the way of direct access to the hardware annoys him. This way of thinking about writing software is not really suitable for mobile development. The problem with writing software for mobile phones (and pdas) is that you need to target as much phones as possible because typically a phone will only be on the market for a short period of time (a few months) and there are a lot of different phones. So if you want marketshare, forget about native C, direct on hardware type solutions. You need to abstract from as much hardware (cpu, memory, screen size, network, storage, input) and software details (which j2me specs, native os, jit or no jit) as possible. That's what J2ME is all about.
That's the theory and maybe it really works on linux. The practice on windows is that if you have a swapfile, windows uses it agressively no matter how much memory you have. That means that for most common uses of windows it is better to turn off the swapfile if you have enough memory because when the swapfile is used, everything (including the application you are using) slows down.
That way windows won't waste your time by pointlessly moving things to and from disk when you really want to get some work done. Diskcache is indeed nice to have. Windows uses all the memory you don't use for that (typically around 400MB in my case).
Of course a typical system doesn't have enough memory. Systems now ship with 256 or 512 MB at most. If you don't upgrade that, you will need a swapfile. If you do upgrade to 1 or even 2GB you take away most, if not all, of the need to have a swapfile. Basically all consumer software is designed to run well on a typical pc. This means that most applications on a typical system will never use more than 100-200 MB. Most advice on swapfile size recommends to use twice the amount of available ram. That's probably good advice if you have 256MB . If you put 1GB in this typical PC you have more ram than you would have had swap space and ram combined on the typical pc.
If you do have the memory, disabling the page file is the best thing you can do performance wise. In theory this is a bad idea, in practice it works very well.
I have 1GB of memory. This is more than adequate for browsing, games, development, photoshop etc. So, two years ago I disabled the page file after discovering that with 300MB in use, windows was still swapping like crazy (and yes I had all the popular registry hacks applied which should prevent that). So eventually I disabled the page file. The immediate result of doing this is that applications become much more responsive. Suddenly multitasking becomes easy and fast.
Normally when you work with an application for a while, all other applications get swapped to disk. It doesn't matter that you have 700MB of unused, readily available ram. So when you try to alt tab to them, windows spends a couple of seconds moving stuff back into memory. This is very annoying and totally unnecessary. The problem only becomes worse if you start to run some memory intensive programs because windows will swap aggressively then.
Disabling the page file fixes this problem. The only disadvantage of doing this is that when you need more than 1GB it isn't there. This is typically the point where things would get very slow anyway due to swapping. In any case, this doesn't happen very often and is easily resolved by closing some applications. All games are optimized to run well with 256-512 MB. Most games don't use more than that, even if it is available. Office applications and other desktop software rarely use more than 100MB. Photoshop can push the limits but unless you are doing some extreme high resolution photography stuff with it, you will not run into any problems with 1GB. It's actually quite hard to run out of memory. Most things that are infamous for memory usage like ms flight simulator, doom 3, photoshop, vmware, etc all run without problems and without swapping.
If you think about it, swapping is a really lousy solution unless you expect to run out of memory. Disk is many times slower than ram. The reason that you open programs is that you want them ready for action. Swapping them to disk is therefore undesirable. The only reason it would be desirable is if the total amount of memory used by all of your running programs is larger than the amount of memory you have. So if you have 256 MB, swap files are a nice poormans solution to the problem that you don't have enough memory. If you have 1GB you shouldn't have that problem (and if you do, buy another GB).
Doesn't matter, the perception is that GPL is limiting redistribution (which it is, even if you are right). If you want choice in the matter (and most companies do), the GPL is not for you. Example, you have a bunch of propietary extensions to some GPL project and you are using it internally (so far so good you say). Then some partner company asks for permission to use your tool. You don't say no to friends so you want to give the software to them. Price is not the issue but opening up the proprietary stuff is. The GPL forces you to choose here and that is a very sound reason to not touch any GPL software that you want to extend.
Of course it is no argument to not use GPL software at all. GPL software is a key component of my development tool chain as I am sure it is for many others. And of course it is no argument against working on GPL projects either. It's not even an argument against the GPL. It's just that other licenses are a bit more flexible in what you can and cannot do. Many companies want this flexibility.
Slashdot Mirror
Your argument is effectively countered by this excellent article on why java memory management is actually faster than the way it is handled in C/C++: http://www-128.ibm.com/developerworks/java/library /j-jtp09275.html?ca=dgr-lnxw07JavaUrbanLegends
In short, memory allocation in Java is faster (measured in cpu cycles used) and it can use both stack and heap based memory allocation (unlike the urban myth that Java can't do that). Additionally, for short lived objects, garbage collection is essentially free (unlike calling free() in C++). Of course you can do clever stuff in C like not actually using malloc and free but most programmers default to not doing except for some very specific cases. In other words, most of the time Java is actually faster for both allocation and deallocation of memory.
People like you run into trouble when they manually call the garbage collector (bad idea, can cause severe performance issues) or when they misconfigure the garbage collector (e.g. if you are running a server with multiple cpus and multiple gigabytes of memory). Also a big issue is C programmers trying to program Java like it is C and making wrong assumptions about the cost of certain code and the impact of certain optimizations (e.g. pooling is actually bad for performance in some cases).
The only real problem that Java has with respect to memory management is that java programmers tend to use lots of memory when writing their software. You don't have to do that but using the default APIs and recommended practices in e.g. the java tutorial and many books on this matter you will probably end up using substantial amounts of memory. Many Java programs continually create and destroy large amounts of small objects. If you'd do that in C/C++ you would really notice this. In Java you hardly notice this at all because it allocates and deallocates in a much smarter way.
I don't know what 'personal tests' you have been performing. Up front I'd say you may have been measuring the wrong things the wrong way and have been drawing the wrong conclusions based on what your results. The JVM is a highly complex piece of software and very difficult to benchmark properly. Doing so requires that you know
I think your reply illustrates my point quite effectively. Nothing you cite is actually worth boasting about but you do. That's the point. You don't like teenagers (you have my symphathy), so you think google's summer of code actually made a difference for end users (naive) and you managed to find two cases where MS actually copied some features from software packages that also run on linux (but have the majority of their users on windows). Good for you.
You think those are major features, I think that's unimportant entry level stuff. If even that wouldn't work right you'd have a pretty shitty tool. The problem with linux desktop software is that
1) their developers are biased to developers. Most of them don't understand the needs of users, especially not when these users are 16 year old highschool girls.
2) their developers have rather strange ideas (for a windows user) about how user interfaces should function and what features are important.
Sure you can do IM on linux. You'll be able to send text to just about any IM network invented, ever. You'll be able to do so from dozens of different clients. And they all look like rather conservative business tools. As does most of the linux desktop.
What's lacking is a forward thinking attitude. Personal communication is a hot thing (and not new at all) and all the linux community does is whine and catch up with yesterdays software. MSN users are used to msn which has a featureset that includes text messaging and a whole lot else. The whole lot else part is actually pretty important to some users. The whole lot else part implemented pretty poorly in msn alternatives (if at all), including miranda-im, gaim, trillian, kopete and other clients I've tried over the years (miranda im is my default client now).
Now what makes me angry is not the fact that this stuff is lacking (I don't care) but that this thread is full of people who are trying to argue away the need for improvement. IMHO this attitude and not any technical limitation is what has been, and will continue to keep linux off the desktop of ordinary users.
What's worrying is not that gaim is such a primitive tool but that its developers are pretty pleased with it. Where's the ambition to implement some cool stuff? Where's the ambition to go beyond what microsoft is doing? This total lack of ambition to improve anything on the linux desktop is what's keeping it back, not the competition (or lack thereoff) from microsoft.
Just look what apple has done in just a few years: they constantly poor out new exciting stuff with a fraction of the number of developers working full time on Gnome and KDE. They too have to deal with Microsoft. But at the end of the day Microsoft looks at apple and not at linux to see what features to clone.
You can't prevent bad/malicious programming of course but you can prevent the vast majority of bugs that are typically exploited by hackers, like buffer overflows or dangling pointers. Java is immune to both these issues. Therefore, Java is a much more secure environment to program in and therefore the use of C/C++ is nearly non existent in the web application domain.
:-). Besides, fixing performance issues in Java is not that hard, if you know what you are doing. But then if you didn't, you shouldn't be trusted with C either.
Infrastructure is a different matter. That too will become the domain of java like languages in the future but for the moment we will need to continue to patch the endless stream of buffer overflow issues in such fine products as apache, iis, bind, openssh, etc. These packages have two things in common: 1) they are written in c/c++ and 2) despite years of security audits and bug fixing, new security issues directly related to C's inherent insecureness continue to be found in them on a regular basis.
True, Java depends on native stuff. In fact most known java exploits are indirectly exploits of bugs in this native stuff. The rest consists of genuine design flaws in the program at hand. However, exploiting bugs in native code from Java is actually quite hard since it involves making a lot of assumptions to the run-time memory usage and garbage collecting. Consequently, there have been relatively few incidents of Java bugs being actually exploited.
In short, if security is important to you, don't even think about using C. Even if you (the programmer) do your work properly, there is no guarantee the developer of the libraries you depend on did. There will no doubt be some in this thread to point out that if performance is important, you should choose C. IMHO these people overrate performance and underrate other important quality attributes like maintainability, security, flexibility, reusability. But who am I to judge these folks
You rightly observe that piracy exists. You imply by your style and wording that this is a bad thing and that the world would be better off if it didn't.
Take away the moralism and the wishful thinking you can deduce the following:
1) piracy apparently exists
2) it is apparently extremely hard to fight legally
3) and therefore it will continue to exist until either 1 or 2 change.
We've already seen over the past few years that fact 1 is unlikely to change by itself (people like free, easy to get goodies) so that leaves us fact 2 to improve on.
In a sense fixing fact 2 is what is happening in the US and a few other countries. However, so far, not to an extent that it becomes measurably effective (instead of obviously counterproductive). The rights of people and corporations are being constrained severely but the effect is 0. These measures have all sorts of negative sideeffects such as companies (even unrelated to p2p or piracy) taking their business elsewhere or going out of business (jobs lost, economy suffers), young people's lives being destroyed and millions of $ being pumped into the legal system instead of being invested more wisely.
Conclusion: moraliststic pricks obsessed with piracy and out of touch with reality are wreaking havoc in our legal and economic systems. I personally think that is a bad thing, much worse than some highschool kids downloading stuff.
There's clearly an untapped reserve of users who need cheap, easy to use design tools. Adobe & macromedia are at the very high end of the market. Their tools are powerful, expensive and intimidating. Sure they have some entry level versions of some tools but these are individual tools, not integrated suits of tools.
Microsoft has cleverly spotted this opportunity.
Also, Microsoft already has much of the necessary technology in various office addons that most people don't even know about (e.g. MS Publisher, photo editor), various stuff from their research department (mainly photo editing), and other stuff like their movie editor. And finally with some acquired components you can build a pretty interesting suite that is not so capable as the high end offerings from Adobe and Macromedia but cheap and usable. That's a good position to start from and over time they'll be able to add features to make the product more interesting.
Ideal for home users that want to edit their holiday pics, ideal for small businesses wanting to make a brochure, etc. In fact good enough for the majority of people who own a photoshop license, a dreamweaver license or an illustrator license. It's amazing how many people buy stuff they don't need. At the office we have a few photoshop licenses. The most advanced thing that ever happens there is to crop a few photos and create some transparent gifs, that sort of stuff. All the artwork we use in our website is actually delivered by professional design studios. Only recently the use of the gimp was promoted for this kind of stuff.
The world is full of users for who photoshop (or it's lightweight derivatives) is overkill or who do not need the full capabilities of illustrator or who do not need to develop complex webpages in inDesign or dreamweaver and who generally feel intimidated by all of the previous tools. Yet these people want to create stuff. They don't want to shop for this tool or that tool. Instead they want the tools on their PC when they buy them. People are lazy, most of them never buy software after their new PC is delivered.
And who happens to have a big influence on what is preinstalled? Right, Microsoft. Imagine how many people will toggle that nice MS Design Studio checkbox on the dell site (hell, why not it's only XX $ and I'll be able to do foo with it). Imagine how many companies will be tempted to spend a few dollars per desktop for this. It's easy money for MS. Even if it's only 1 percent of their users, that still is a huge amount of money.
You could argue that they are abusing their market position. You could also argue that other companies have simply failed to fill this gap in the market for years. Adobe only recently started to make consumer versions of their tools. You need to buy them individually and the full suit of tools is for high end users with big budget only.
Some elaboration:
1.1) Also clean out the program directory. Make sure to backup any search plugins and plugin dlls because you may be able to reuse them.
2.1) When you launch move the plugin dls back to the plugin directory, don't overwrite existing files (probably newer)
2.2) Copy the searchplugins to the searchplugins dir
2.3) Copy the bookmarks, cookies and passwords from your old profile to the newly created one
3) this step is not possible because you have a new profile: reinstall all of the extensions you want to use
Im not going to read the article but the reasons stated in the summary suggests a strong (and maybe well funded) bias. In short, the summary is basically bullshit. The quoted material on the ms blog is suspicious and the scientific study might actually be quite good (I wouldnt criticize it without reading it first).
.Net come with very similar security features. Both have finegrained role based security features. Id say Java is somewhat more flexible by providing an extensible model so that you may provide your own protocol implementations. For example, I used an oss pgp implementation recently that plugs into the default Java security api. .Net on the other hand has some nice language features like attributes. Java has null securitymanagers; .net has unmanaged code.
Security is not something you just switch on in a project. You design your project from the ground up to have security features. Both Java and
Javas security features are designed through the JCP process in which a broad range of industries and individual experts have been and continue to be involved. Indeed some of the older security features come from the earlier JDK versions developed by SUN. Overall I trust this process more than I trust the microsoft process which when it comes to security has received a lot of criticism over the past few years.
I can see your problem. High school kids are not computer science students so you need something simple. You want to teach them something useful that will help (and motivate) them to possibly consider taking a bachelor/master in an IT related field.
I was about to recommend Java. But I think that might be too abstract for high school kids. You'd probably end up scaring most of them with it (and I am a Java programmer). The nice thing about VB was that it is simple, gets results quickly and that there used to be a market for VB programmers. This market (and the market for fat clients) is disappearing rapidly.
So you need a replacement that is easy to learn for not particularly talented high school students, gets results fast and has some reasonable demand in the job market. That excludes legacy stuff like pascal, delphi, vb; obscure scripting languages such as perl, ruby.
Php is popular but is a bit the C++ of scripting languages: you can do lots with it and you'll likely shoot yourself in the foot. In other words it's not the ideal language for teaching. So I point you to similar languages like jsp and asp.net. You can do similar stuff with those technologies. In the case of jsps there is java behind it and lots of useful taglibs to do difficult stuff. You get results quick; web pages are something every high school kid understands. There's definately market demand for jsp programmers. Asp has similar advantages and may be a logical successor to your VB based course. Tools might be a final consideration. Microsoft can be expensive but they are known to make deals with educational institutions. Java/jsp tools are available for free but come with requirements that might exceed what you have in the school computer rooms.
You can actually disable the bloat in xp. I installed windows xp on a 1997 pentium II 233mhz with 64 MB once. Both cpu and memory were way below the official required spec. And of course the out of the box experience with everything on was nothing to write home about but it worked. If you strip it you are left with an improved version of windows 2000. The kernel is a mere minor version increment over windows 2000. The rest is just services which, mostly, you probably want turned on if your machine has enough memory. Since memory is dirt cheap, do youself a favour and quit trying to shave kbytes of the memory usage and install 512MB (or more).
I agree some services are probably not very useful and indeed ms windows has not been designed for computers that already shipped with an OS in the last century. Can't really blame them because there is no market for such OSes.
Now (i'll take the bait) the Java language is another thing. At a mere 15.54MB download (just checked), the jre packs a whole lot of functionality. Of course the development kit is somewhat bigger at 56.71 MB but still pretty ok if you consider that A) you don't need it unless you do development and B) it includes examples, the full jre, tools and source code for the libraries all in one package. And it will work on your favourite last century OS win2k of course. Hardly bloated in a time where broadband is cheap and widely available and pcs ship with 120GB or more of diskspace. I'd certainly would not want SUN to remove features to please a few whiners like you.
Anyway the idea of pcs is that they are cheap. It will run the software it came with just fine. Maybe if you spent some money it will live through a few software upgrades (say it came with windows me, you upgraded it to win2k: good for you). After that, be happy the thing still works and spend the money on a new PC if you want the latest and greatest. A 1000$ should keep you happy for another few years.
Agree. It would be quite ironic that one of the most violent games of this moment would be banned from the shelves because of some sex feature that is not even enabled by default. The mere suggestion of sex (it's not more than that) is enough to provoke this kind of reaction, the simulation of city wide riots, gang wars and drug violence is not.
:-). However, I can imagine parents being a bit concerned about the violent nature and the reference to whores, drugs, criminality, etc. You probably don't want your toddler playing this game. However I have no respect for the people who think that this is ok and yet somehow the sex thingy is not.
It's also ironic that the same people who freak out over accidental nipples on tv look the other way when it comes to guns. It's ok and considered normal to handle a gun at fifteen but you can't legally have sex until three years later. A beer takes another five years. Someone not to be trusted with alcohol can safely handle a gun according the US law. That's just fucked up. And speaking of swearing, it's ok to put a bullet through someones head on prime time on tv. But if the guy on tv says "fuck, that hurts" you hear a little beep. IMHO the visual depiction of someone being shot through the head is probably a bit more shocking to a minor than someone using the F word.
The people who rate movies, games, etc. and the people who inspired the whole notion of rating have got their priorities the wrong way around.
BTW. GTA is great fun
depends on your definition of art (there appears to be authorative definition of the word art anyway). I'm not really interested in either the definition or the answer to the question.
But then the question is typically asked by programmers looking for a justification of their work. Hint your not an artist but an engineer. Others will judge by your engineering qualities, not by your artistic skills. If the code is beautiful crap it's crap to the outside world. It might be a work of art to you but nobody will care until you fix it.
I agree, the current trend is very much in contradiction with closed model the irrelevant publishers make their money from. I say irrelevant because there is a disconnect between scientific content production (by volunteer scientists), scientific content reviewing (by volunteer scientists), and scientific content consumption (by basically anybody who cares) on one side and the publishers on the other side. They used to have a significant role in replicating and distributing content. Basically the internet has obsoleted them so why exactly do we keep giving them money from precious research grants?
Different discussion. However back on topic. Publishers are unlikely to protest against authors putting pdfs of their articles online. Incompetence is of course a big reason (no doubt inspired by indifference). They simply have no clue what is going online. They sincerely believe they have an important scientific role. In reality they just put ink on paper (for a ridiculous price). The entire scientific process is external to them (writing & peer review).
It's just a matter of time because the scientific community moves away from the traditional publishing model. Already google is important for article citations. If it is not online, it is less likely to be read. Personally I strongly disliked having to deal with libraries & librarians when I was still in university. The whole process is slow, tedious and time consuming (usually weeks because a photocopy had to be snailmailed from some distant other library). If I can't find the pdf online I am unlikely to walk to the library unless I really want to read the article (for example moore's orinal article on moore's law, interesting read).
The google factor is undeniable. If you are not online nobody reads your articles these days.
The question is not whether google is good enough but wether the commercial offerings are good enough.
As others point out google scholar is free. Generally commercial solutions aren't and work on subscription basis.
Furthermore google scholar works by basically more or less the same strategies as regular google. Put some search terms in the box and relevant search results will surface. This is a different strategy than the traditional solutions which index many different kinds of metadata and allow for elaborate searches based on that metadata. Both strategies have their place but eventually price and convenience will determine who dominates the market. If simple queries are your thing, google scholar is the preferred search engine. If you are a fussy librarian, you probably need something more sophisticated.
I'm a researcher who is not associated with a research institute and thus has no access to academic search engines, online subscriptions, etc. I do have access to google scholar. If your article shows up there with a download link for the pdf I can read it. Otherwise I have to make an effort to read your article. The way scientific publications work has changed over the past few years. Journal publications give you status, google gives you exposure. Many researchers end up reading my articles after doing a google query, not after consulting a table of contents of some journal. Google is convenient that's why it works so well.
I have a number of different use cases that are typical for me:
- get some useful references on a topic
- look up the correct reference for something you have read
- find stuff written someone you've read other stuff from
- find out who is citing you
All these things google scholar does well. If you are a researcher it is in your interest to make sure google returns relevant search results if people look for your work stuff that is related to your work. Putting your articles on a website is all you need to do.
.. what would happen if Apple decided to just offer the OS without the hardware? MS is in an enviable position of having a monopoly on x86 pc operating systems. There is some competition but none of it is taken seriously at the moment (except for servers). Even cost conscious companies choose windows over linux for their desktops.
Mac OS X x86 fixes this.
It's got a unix touch yet it is user friendly (unlike almost any other flavor of unix). It performs well and doesn't suffer from any of the trademark Microsoft deficiencies (security fixes every week, poor usability, an indifferent software vendor, the occasional BSOD & a hefty pricetag). Users apparently seem to like it and there's a decent selection of OSS and commercial desktop apps (including MS office!).
Apple should be able to get 5% marketshare of the PC OS market within a year or so. I expect that there is a turning point where the marketshare will grow rapidly at the cost of windows. For example, a deal with Dell might be such a turningpoint. That means a steady flow of revenue that outperforms anything that can be realized through Apple hardware sales. Most of it is profits because they already did the hard work of writing & porting the software.
I'm actually wondering why they wouldn't do this.
I don't use linux. Obviously desktop linux is not a priority for IDE developers. SWT has basically sucked big time on linux and nobody seems to care. In the absense of a unified, consistent native look and feel, the swing L&F is probably not so bad under linux.
Eclipse fanboys assume eclipse is faster because of SWT. And that is my whole point. On windows this performance advantage does not really exists and eclipse is noticably slower than the swing based netbeans. Apparently other factors than GUI toolkit are an issue here.
I use eclipse every day: it is slow. IBM was mistaken in thinking that SWT was a solution for performance issues in IDEs. I work with eclipse on a daily basis. I recently replaced 3.0.2 with 3.1M7. I've given up on the myeclipse J2EE plugins because these bring my system down to crawl. Netbeans offers similar features to the eclipse + myeclipse combo and is noticably faster on the same projects (basically the only thing eclipse does well IMHO is editing java code). By faster I mean that the dialogs are more responsive, I spend much less time waiting for the IDE to finish validating, manipulating large project trees in the project explorer is fast and responsive.
The rendering myth is bullshit both swt and swing use native, hardware accelerated routines to do the rendering. SWT uses native gui libraries to do this, swing uses java2d which in turn uses either directx or opengl depending on what os/vm combination you use. Rendering stuff on the screen is not an issue with either. SWT basically suffers from the same performance bottleneck as Swing: the event queue and rendering logic share the same thread. This means that lengthy event handling code blocks the UI. The solution is using a worker thread to off load lengthy operations. Using worker threads everywhere was the big improvement in netbeans 4.0 and is the reason why you are now seeing reports everywhere on netbeans outperforming eclipse. Good swing applications use worker threads. Many swing applications are coded by people who don't understand threading though. The same is true for swt. If you understand how to use threading you can build nice responsive UIs with both.
The eclipse UI blocks frequently. Opening/closing a large project tree is a good example. In netbeans there's no delay no matter how big your project is, in eclipse there is a noticable half second freeze even on small projects. Eclipse frequently freezes for a few seconds.
3.1 M7 is actually quite an improvement performance wise but they've not catched up with netbeans yet and will have to do much more to compete effectively. If you read the changelogs you'll see they are full of performance fixes. Apparently there are lots of performance issues to fix.
The reason I continue to use eclipse rather than netbeans is the Java editor. It is simply much better & smarter than the netbeans code editor (though slightly less responsive). I don't care for project wizards, I just want a smart code editor that helps me rapidly poor out code. Refactoring and code completions are where eclipse really shines. The debugger is nice too and quite handy if you install the right plugin for integrating with tomcat.
Agreed, for that kind of money you basically already have the best solution. Assuming your goal is to cut on the 15000 dollars and not push some idealist OSS agenda, you are not going to make any substantial cuts this way. Plus, your 'clients' (the students & staff) will probably complain loudly if you take away the software packages they are used to. At 15000$ the cost argument is ridiculous so you'll have a real hard time explaining why they have to use open office instead of ms office. Unless you remove IE from the system (which boils down to replacing the OS), people are going to click that blue IE icon.
What you'll end up with is a complicated mix of operating systems, offices suits and browsers that you will need to support. You will increase cost rather than cut cost. Forget about eliminating MS from your systems, you'll end up doing all the work you do now + the additional work for maintaining your home built linux enterprise management kit (I'm assuming you are not interested in commercial linux support with per seat licensing).
This has been posted in the last thread on svn and I don't agree. I've used subversion for more than a year now. I find it to a be a very reliable and easy way to put files under version control.
The reason cvs fanboys love having textfiles around is that, well, you really need them in the not so unlikely case that cvs messes up. One of the many things that svn fixes is atomic commits. In svn a commit either fully succeeds or fails. In cvs on the other hand it may actually fail halfway and leave the repository in an inconsistent state. When that happens, ascii files on disk are quite nice to have.
Svn fixes this by using a database and by not commiting changes to the database until everything is ok (not rocket science but nice to have when you are working with your most valuable assets: source code). In addition you can of course make incremental backups (on the fly) of any svn repository using svndump (which outputs a nice ascii representation of all commits in the order they occured). If you are really paranoid, you can do this every ten minutes (because it is incremental) and backup the db files every night.
If the worst happens (diskcrash?), you have the svndumpfiles, database backups and your user's local work directories to work with. That should provide everything you need to recover all data. If not, it is not a technology problem but a matter of backup discipline.
Now for all cvs users, migrating to subversion is as simple as creating a svndump file with cvs2svn and loading this dumpfile with svnload. Versionhistory, tags, branches etc. is migrated completely.
I mean broken as in from that point apt-get throws errors about various executables and libraries not being found on any subsequent attempt to install something (even the most trivial packages). In my book that is a serious situation that should not occur no matter how broken the package is. As for debian documentation, I've been conditioned over the years to expect that linux documentation (specifically debian documentation) is usually incomplete, out of date and quite often incorrect and internally inconsistent. Don't blame me for not rtfm'ing. In this specific case I was following the steps outlined in some howto on getting a debian desktop working. Clearly the howto was out of date and as I experienced incomplete and in some places incorrect. It fully met my expectations.
The problem with your attitude (which is illustrative of how the debian community deals with end users) is that it argues away the problem. The problem is that apt-get can break down and that you need expert help to fix it. The problem is not end users ignoring available documentation (this is actually one of the few predictable things in software engineering). The whole point of apt-get is that it shouldn't break down, that you shouldn't need to fix it, that it fails gracefully in case of problems and that you can install stuff without reading piles of installation howtos.
The problem with debian testing is that it is in a more or less permanent state of being broken somewhere (that's why it is called testing and that's why it is not suitable for end users). Install the wrong package and you end up with a broken system that can only be fixed in a non trivial way. Complex packages like X, gnome and kde are always a challenge to get working on debian because of this. Sometimes it will work sometimes it won't. In fact, no debian testing install I have used has lasted more than a few days because of this. Invariably I ended up apt-getting a package that apparently I shouldn't have touched. Once things break down it can get ugly quickly.
There's nothing wrong with the philosophy in theory. There's a lot wrong with the philoshophy in practice. If you install debian stable desktop apps you are running software with many bugs (including security bugs) that are not being patched by the original developers because they've moved on to versions that probably include a lot of relevant fixes & features. In addition you are missing out on four years of significant feature development (the stuff in stable was obsolete when woody was released). Four years is a long time for desktop operating systems (cough, microsoft are you listening?).
.deb format over rpm. Now poof, compatibility problems between debian and ubuntu. What's going on here?
When's the last time you saw a KDE 2.x update? A Mozilla 1.0 update? Nobody is maintaining this stuff anymore, except for the debian guys.
IMHO the KDE guys are much more qualified to fix KDE than the debian guys. I can understand that you might want to wait a few months before incorporating a KDE release in a distribution. But the debian guys are behind a lot of versions and they're not even trying to keep up. And this is the case with most major packages in Debian. They're shipping stuff that the original developers no longer care to maintain. Really when's the last time you installed a mozzilla 1.0 patch or a KDE 2.x security update?
When you are running a server this doesn't really matter much because on a server you don't constantly install new software but instead you focus on a handful of server applications (e.g. apache and mysql). You can afford to compile the latest versions of those applications yourself if you need to. This is what debian is good at: laying a good foundation for running a handful of customized server applications that really matter to you. I'd pick debian if I needed to run a stable linux server.
However, this philosohy doesn't scale well to the desktop. Almost all debian desktop users run testing or a debian based distro derived from testing. Testing is not that good. On all occasions I tried it I managed to freak out apt-get in no time with a very small number of apt-get installs, updates and upgrades. Last time (two weeks ago) apt-get install kdebase did the trick. Poof errors all over the place. Probably it was fixable but it shouldn't need fixing in the first place. Debian users recommend using testing for desktops, I'd recommend using a finished and tested product instead. There are plenty of those around. Some are even derived from debian testing. Ubuntu is currently doing what the debian community is currently not doing: supporting end users.
Interestingly the debate shows that maybe the deb package format is not so perfect. Wasn't the package format intended to prevent this kind of compatibility problems? For years the debian people have been claiming the superiority of the
Not yet. The problem with j2me is that there are so many implementations (and some of them really suck) of it. Some have JIT, some don't. There are a lot of hardware/software combinations. And that makes testing really hard. Of course you have the same problem if you move to another language. Because of that, there is not a lot to choose from. Brew and J2ME are basically it. Brew is optimized for gaming and J2ME targets a wider variety of software applications. Brew is a traditional, proprietary solution whereas J2ME is much more open with free development kits, documentation, etc. As Carmack notes, it is much easier to get started with it.
An additional problem is that the core J2ME specs don't cover much functionality. All the interesting stuff is in optional modules which may or may not be implemented on a J2ME phone. There's a whole range of J2ME specifications that may or may not be implemented.
John Carmack reasons very simple from a game developer point of view. Basically anything that gets in the way of direct access to the hardware annoys him. This way of thinking about writing software is not really suitable for mobile development. The problem with writing software for mobile phones (and pdas) is that you need to target as much phones as possible because typically a phone will only be on the market for a short period of time (a few months) and there are a lot of different phones. So if you want marketshare, forget about native C, direct on hardware type solutions. You need to abstract from as much hardware (cpu, memory, screen size, network, storage, input) and software details (which j2me specs, native os, jit or no jit) as possible. That's what J2ME is all about.
That's the theory and maybe it really works on linux. The practice on windows is that if you have a swapfile, windows uses it agressively no matter how much memory you have. That means that for most common uses of windows it is better to turn off the swapfile if you have enough memory because when the swapfile is used, everything (including the application you are using) slows down.
That way windows won't waste your time by pointlessly moving things to and from disk when you really want to get some work done. Diskcache is indeed nice to have. Windows uses all the memory you don't use for that (typically around 400MB in my case).
Of course a typical system doesn't have enough memory. Systems now ship with 256 or 512 MB at most. If you don't upgrade that, you will need a swapfile. If you do upgrade to 1 or even 2GB you take away most, if not all, of the need to have a swapfile. Basically all consumer software is designed to run well on a typical pc. This means that most applications on a typical system will never use more than 100-200 MB. Most advice on swapfile size recommends to use twice the amount of available ram. That's probably good advice if you have 256MB . If you put 1GB in this typical PC you have more ram than you would have had swap space and ram combined on the typical pc.
If you do have the memory, disabling the page file is the best thing you can do performance wise. In theory this is a bad idea, in practice it works very well.
I have 1GB of memory. This is more than adequate for browsing, games, development, photoshop etc. So, two years ago I disabled the page file after discovering that with 300MB in use, windows was still swapping like crazy (and yes I had all the popular registry hacks applied which should prevent that). So eventually I disabled the page file. The immediate result of doing this is that applications become much more responsive. Suddenly multitasking becomes easy and fast.
Normally when you work with an application for a while, all other applications get swapped to disk. It doesn't matter that you have 700MB of unused, readily available ram. So when you try to alt tab to them, windows spends a couple of seconds moving stuff back into memory. This is very annoying and totally unnecessary. The problem only becomes worse if you start to run some memory intensive programs because windows will swap aggressively then.
Disabling the page file fixes this problem. The only disadvantage of doing this is that when you need more than 1GB it isn't there. This is typically the point where things would get very slow anyway due to swapping. In any case, this doesn't happen very often and is easily resolved by closing some applications. All games are optimized to run well with 256-512 MB. Most games don't use more than that, even if it is available. Office applications and other desktop software rarely use more than 100MB. Photoshop can push the limits but unless you are doing some extreme high resolution photography stuff with it, you will not run into any problems with 1GB. It's actually quite hard to run out of memory. Most things that are infamous for memory usage like ms flight simulator, doom 3, photoshop, vmware, etc all run without problems and without swapping.
If you think about it, swapping is a really lousy solution unless you expect to run out of memory. Disk is many times slower than ram. The reason that you open programs is that you want them ready for action. Swapping them to disk is therefore undesirable. The only reason it would be desirable is if the total amount of memory used by all of your running programs is larger than the amount of memory you have. So if you have 256 MB, swap files are a nice poormans solution to the problem that you don't have enough memory. If you have 1GB you shouldn't have that problem (and if you do, buy another GB).
Doesn't matter, the perception is that GPL is limiting redistribution (which it is, even if you are right). If you want choice in the matter (and most companies do), the GPL is not for you. Example, you have a bunch of propietary extensions to some GPL project and you are using it internally (so far so good you say). Then some partner company asks for permission to use your tool. You don't say no to friends so you want to give the software to them. Price is not the issue but opening up the proprietary stuff is. The GPL forces you to choose here and that is a very sound reason to not touch any GPL software that you want to extend.
Of course it is no argument to not use GPL software at all. GPL software is a key component of my development tool chain as I am sure it is for many others. And of course it is no argument against working on GPL projects either. It's not even an argument against the GPL. It's just that other licenses are a bit more flexible in what you can and cannot do. Many companies want this flexibility.