Fitting the kitchen sink onto a CD
- on 2009-04-19
- Rants
- 133 Comments
Ubuntu’s main installation method comes on a single bootable CD. By today’s standards, a CD is a rather confined space – as a result, every last megabyte is considered precious. A single stray megabyte could push the CD over the limit, and make it worthless – and a few saved megabytes could help make the disc more multi-lingual, or mean more exciting apps. There are rumblings from within the bowels of #ubuntu-devel that OpenJDK would be a nice thing to include – but this is essentially impossible unless someone can magic over a hundred meg of space onto the already hard-pressed CD.
As a team, the Debian Mono Group (which is these days a joint Debian/Ubuntu effort) have helped to reduce our footprint by a good few meg in the Jaunty cycle, as part of the Mono 2.0 transition. And now I have a proposal which I’m going to make to the Desktop team at Ubuntu Developer Summit in May, which will save six precious megabytes.
That’s right, kids. To save a significant amount of space (6.1 MiB), we dump bloated C-based Rhythmbox and include svelte lightweight C#-based Banshee. The numbers may astonish C die-hards, but they’re true – similarly, Gnote’s binary is twice the size of Tomboy’s binaries, even though it has no plugins (it only appears smaller thanks to having no documentation). Removing Rhythmbox and all its Rhythmbox-specific dependencies decreases the size of an Ubuntu Jaunty install by 18.4 MiB; installing Banshee 1.4.3-4 (with all Recommends, of course) adds on 12.3 MiB. The 6 meg difference could be the first 5% of OpenJDK inclusion. Or it could be two extra languages. Or it could be a cool new tool (Gnome-Do, anyone?).
Running the numbers also involved testing other players. Songbird is a no-go (42.6 MiB, and a RAM footprint to crush small towns). The smallest entrant was Quod Libet, but version 2 of that seems to have a UI designed by MC Escher, which isn’t really an appropriate direction for the default player. RAM consumption compared between Rhythmbox and Banshee rules in RB’s favour, but not by too much (about 60 meg versus 50 meg in the testing I did).
Perhaps the most important detail, though, is that Banshee development is active and vibrant, with new features being added every release. This fits into Ubuntu’s raison d’être far better than the somewhat maintenance-only development Rhythmbox has been seeing. Even if the desktop team rule that Banshee isn’t appropriate for one reason or another, I’m pretty confident that upstream could fix each and every concern by the time Ubuntu 10.04 rolls around. So that’s the proposal! Let’s see how it plays in Barcelona at UDS.
Yessss! I have been waiting for someone to step up and make a proposal. Will lead to heavy discussions but I’m sure banshee will be the winner. It’s far better than RB.
[Reply]
What’s the theme you’re using? it kicks ass!
[Reply]
directhex Reply:
April 19th, 2009 at 3:02 pm
@Bokal, It’s one of the new themes in Jaunty, called “New Wave”. gnome-themes-ubuntu package.
[Reply]
I agree. As I wrote in my book “After the Software Wars” we need to kill user-mode C/C++ and replace it with managed code, either C# or Python. This moves us an important step in that direction.
But let’s keep totem for now as I like the option to have a very lightweight media player. One thing Banshee needs to fix is widen the audio position scroll bar. I have some audio files that are hours long and so I need something to move around in the file.
[Reply]
directhex Reply:
April 19th, 2009 at 5:02 pm
@KeithCu, I absolutely agree about keeping Totem – I feel it’s important to have a “file player” as a task (which Totem fulfills well), and a “media library client” which apps like Rhythmbox and Banshee take care of
[Reply]
I think Totem can be eliminated as well if Banshee improves a “mini” mode to look and behave pretty much exactly like Totem does today. That will help to save even more precious space so we can fit OpenJDK on the CD!
[Reply]
Oh no, not another one to fall deeper into the Mono-trap
[Reply]
Stifu Reply:
April 20th, 2009 at 5:15 pm
@fana, Oh no, not another one to fall into the FUD trap… ¬_¬
I can only hope Banshee gets to replace Rhythmbox as proposed here, but with the constant destructive attitude from anti-Mono people fighting to strip every single Mono byte out of Ubuntu (and other distros), it may not be easy.
[Reply]
Ok do you know why the native code binaries are so huge.
Basically you have missed the problem. Its gcc. Rebuild them with llvm or pgroup complier you will learn that .net is bloated and native executable are bloated. Rebuilt with llvm is lower on ram and disk usage. Problem with mono is performance not memory and disk usage.
Before you get bench marks of gcc vs mono. Of course mono should win. Gcc has no link time optimization so executables are highly bloated and very low performing.
Projects are fixing up Gcc cutting at least 7 kb of every native executable and library in the complete system. Even something super simple like #include n int main(){} There is 7 kb of waste in a executable produced that is 8 kb in size so yes 8 to 1 at times will be possible. Even 1 kb for that executable has waste true bare min is a tiny 100 bytes without doing evil things. Some cases its many mega bytes per application. The effect on performance of these reductions. Way faster.
The 6 meg difference is nothing. There is way more waste in the native binary than 6 megs. Sorted out gcc even the Linux Kernel itself can be smaller and faster. Even dependencies mono require to run can give up over 6 megs.
http://gcc.gnu.org/wiki/LinkTimeOptimization Basically forget mono and focus on where the real saving in ram disk and cpu usage are.
[Reply]
directhex Reply:
April 20th, 2009 at 12:20 pm
@oiaohm, There’s a SoC project to use an LLVM back-end in the Mono JIT, which could be nice – the benefits you tout, along with the ease & simplicity of Mono development
[Reply]
Miguel Reply:
April 20th, 2009 at 4:11 pm
@oiaohm,
Saving a couple of kilobytes here and there by a link-time optimizer will not help any situation where the dependency comes from system libraries, as system libraries expose APIs that are required on the system beyond the use required by a single application.
There is a simpler alternative than switching to llvm and it is to use gcc and optimize the code for size, not speed and maybe that could provide some savings.
Please go and compile RB with llvm/gcc for size/etc and come back with actual data from the actual programs, not anecdotes about “hello world”.
[Reply]
I know about that project. Sorry JIT has its disadvantage. AOT so you remove the need to process executable to run. Problem is you end up with a native binary again along side the bytecode. So sorry max performance .net is bloated. Max performance comes from a well processed AOT binary no startup lag. As soon as you use AOT all that saving by shipping with .net bytecode disappears on the installed system. Same with JIT caching. So you saved in the installer disk and cost on the users hard-drive. So all you have done is moved the disk usage. Its even worse JIT cache of mono is per user. So you have completely blown out disk usage 6 megs don’t go far spreed over 200 users.
You cannot get away from the problem of native binaries. Does mono use GTK yes it does. GTK is C not .net so you will always have bloat there unless you fix the complier for the system core. All the system libraries have more bloat than what you are saving using mono. Then there is the bloat of the .net wrappers to gtk and the like. Again consuming more disk-space.
Mono is basically bloated to hell. Native binaries are also bloated to hell so .net looks better.
Fixing the complier may not be as small on the installer disk but on users cpu, harddrive and ram usage savings. Those savings come very important when you are running clients Disk Less Remote Boot or LTSP.
So you want mono development no problem. Bring it into line with what is need. Cut the bytecode out go native.
Before you say processor optimizations sorry they system already has one bytecode the cpu native code lack of a reprocessor of that bytecode is a issue. You cannot get away from these issues just by putting another bytecode on top. All you introduce is more problems.
Reprocessors of binaries have existed in the past allowing ppc code to run on x86 and x86 code to run on ppc. There is really no need for a common platform bytecode other than the pure lack of time spent developing a great reprocessor.
[Reply]
Miguel Reply:
April 20th, 2009 at 4:16 pm
@oiaohm,
This seems like a long incoherent rant.
For the LiveCD you can use CIL instructions just fine, you do not need to have any code pre-compiled. I doubt very much that people use a “LiveCD” for maximum performance
For people that decide to get the most out of the system, they can opt into using AOT compilation.
And yes, CIL bytecode executes more code than C code does. And C executes more code than assembly language does. But high-level languages exist for a reason: because they are easier to write, easier to debug, easier to maintain, easier to expand, easier to innovate and easier to adjust to changing conditions.
Nothing will beat a hand-tuned assembly piece of code, but it will not be very agile.
It is a matter of balance. Considering that there are only so few engineers working on these software projects (as opposed to users with strong opinions as to what technology must be used) you would think that getting more bang for the buck would be in Linux interest’s.
On the other hand, I look forward to an assembly-language version of a media player, it really can not be that difficult.
[Reply]
sudo apt-get remove libmono0
The following packages will be REMOVED
f-spot gnome-rdp libart2.24-cil libflickrnet2.1.5-cil libgconf2.24-cil
libglade2.0-cil libglib2.0-cil libgmime2.2a-cil libgnome-keyring1.0-cil
libgnome-vfs2.24-cil libgnome2.24-cil libgnomepanel2.24-cil libgtk2.0-cil
libmono-addins-gui0.2-cil libmono-addins0.2-cil libmono-data-tds2.0-cil
libmono-data2.0-cil libmono-getoptions2.0-cil libmono-posix1.0-cil
libmono-posix2.0-cil libmono-security2.0-cil libmono-sharpzip2.84-cil
libmono-sqlite2.0-cil libmono-system-data2.0-cil libmono-system-web2.0-cil
libmono-system2.0-cil libmono0 libmono1.0-cil libmono2.0-cil
libndesk-dbus-glib1.0-cil libndesk-dbus1.0-cil libvte0.16-cil mono-2.0-gac
mono-2.0-runtime mono-gac mono-runtime tomboy
0 upgraded, 0 newly installed, 37 to remove and 98 not upgraded.
After this operation, 48.8MB disk space will be freed.
sudo apt-get remove rhythmbox
Reading package lists… Done
Building dependency tree
Reading state information… Done.
The following packages will be REMOVED
rhythmbox
0 upgraded, 0 newly installed, 1 to remove and 98 not upgraded.
After this operation, 14.8MB disk space will be freed.
Whoops. Maybe I’m doing something wrong.
[Reply]
directhex Reply:
April 20th, 2009 at 2:16 pm
@Louis Bates, You are. Firstly, use aptitude, and run an “aptitude dist-upgrade” after removing Rhythmbox, in order to catch RB’s orphaned dependencies. Secondly, you’re removing more than just Banshee – Ubuntu comes with F-Spot and Tomboy, and therefore comes with a bunch of Mono stuff already (the same way it comes with things like GTK+ already). You’re hardly comparing like-for-like here.
[Reply]
Louis Bates: in addition to DirectHex’s answer, Banshee does not depend on half of those packages. You are removing every mono package you could possibly install (not just the REQUIRED packages to run the 3 mono apps in that list). And then of course, you are removing 3 Mono applications compared to 1 native application.
Next time try not to make it so obvious you are a disingenuous troll.
[Reply]
True. We just need an f-spot equivalent to remove the mono stack in it’s entirety.
Looking at Rhythmbox’s dependencies, you’ll only get rid of most of them by removing gnome. OK libmusicbrainz, maybe.
I know a lot of people really like Banshee. Personally I much prefer Rhythmbox. I know people who prefer Amarok to Rhythmbox but I don’t personally know anyone who’s switch from Rhythmbox to Banshee. Most people using Ubuntu seem to get on with Rhythmbox.
With your link to the no software patents campaign, don’t you worry about making Ubuntu more reliant on Mono? Microsoft even appear to have patents on elements of C#. How the hell does that work for a standard? In light of the TomTom case, it worries me. Maybe the way to C# on Linux is via Vala.
[Reply]
directhex Reply:
April 20th, 2009 at 4:16 pm
You can check archive.org to see how long I’ve been against software patents (hint, my old domain of apebox.net will need to be searched). And no, I don’t worry about making Ubuntu more reliant upon Mono. Not in the least. Firstly, I don’t think it makes business sense for Microsoft to attack Mono. Secondly, the packaging has been designed from day one to minimize risk (hence why, for example, no WinForms is included by default in Ubuntu’s Mono). Thirdly, the presence of strong Mono applications can only serve to encourage competition from other projects.
Frankly, I can’t envisage any patent violated by Mono but not by either Java or Vala. And Microsoft’s list of claimed patents covers so many fundamentals, the best solutions seems to me to be “treat the patents as worthless, don’t treat them as sacred”
[Reply]
Technology Reply:
April 20th, 2009 at 4:18 pm
@Louis Bates,
Agreed with DirectHex comment on:`the best solutions seems to me to be “treat the patents as worthless, don’t treat them as sacred”’.
If you were not, you would have to start worrying about OpenGL patents that were acquired by Microsoft in 2002 or the COM patents that permeate Firefox, Thunderbird, XUL, VirtualBox and OpenOffice.
[Reply]
@Jules
I’m really not trying to troll. I was trying to be a bit humourous with the libmono removal.
I’m certainly not convinced by Mono, as a technology. As a developer who writes writes in C and C++, I can very much see the benefits of higher level languages for rapid development. I can see the advantage in Mono in easing cross-platform development. But somehow the cost still seems too much.
@directhex
I wouldn’t have thought it would make business sense for Microsoft to attack the Linux LFN implementation, yet they appear to hav just done so. In terms of it making business sense, I would agree that until Mono has well monetised development relying on it, it won’t make much sense. Once there is a whole stack of applications that Microsoft could effectively move to Windows simply by removing Mono, I think it will make more business sense. The other route of requiring payment to Microsoft for Mono usage doesn’t seem too far fetched either.
You are right, in that a software patent threat can come from any corner and hit any technology. With the patent trolls around currently, this is something that is hitting many software companies. Microsoft seem to have to pay off a patent troll every few months and smaller companies like Red Hat seem to suffer too.
There seem to be two differences to me on an IP front between Mono and something like Samba. Samba has effectively had a pass from the European Union to be doing what they are doing which resulted in a royalty free deal with Microsoft and they allow interoperability without the result of that interoperability being a further tie to the technology. I’m not sure I’m being super clear there.
Mono on the other hand could really do with the same kind of license that Samba has, an understanding that it’s a technology to allow interoperability and that Microsoft, as a monopoly, need to allow it to thrive as an alternative.
I think we agree that all software patents are effectively worthless, the problem comes in that courts don’t currently think so, even post-bilski, and it seems to be the guy with the biggest pockets who succeeds more often than not.
I know Microsoft were quite involved in the port of Silverlight to Linux and I wonder if that would confer a license in principle to the entire mono stack.
[Reply]
There is no such thing as a “Royalty Free Deal with Microsoft” with Samba, that is an incomplete summary of what the deal actually is.
Microsoft must provide a list of patents that they have and that Samba might infringe to Samba core members have a chance to work around them or avoid their use. Samba is responsible for not infringing or finding a work-around the issue.
But if they fail to do so, then the code infringes and it is suitable for negotiation with the patent holder.
[Reply]
Louis Bates Reply:
April 20th, 2009 at 5:13 pm
@Technology,
Sure, you are right. Beyond what you state there was a one off payment with no ongoing royalty.
It seems like the kind of deal that Mono could really do with.
[Reply]
[…] the weekend a couple of interesting post were made: In “Fitting the Kitchen Sink into a CD” Jo from the the Debian/Ubuntu Mono developers and describes how the way they have split Mono on […]
Hello,
To come back to the subject (replacing RB with Banshee) –and I sincerely hope you’ll succeed, because of your “vibrant community/development” point–, please just remember one thing:
It is one thing to add an application, it is another to _replace_ one. Please take extreme care to the migration of user data and importing as much config as possible from rhythmbox. Some apps/transitions are/were good at this (Firefox, Tomboy properly configured with the “Sticky notes importer”), some apps not that much. I read for example that BitTorrent replacement by Transmission in Ubuntu 8.04 has been quite a pain for some users losing torrents, config files, etc.
So hey, all this may already be covered by Banshee (and I don’t even know it cause -uh- I’m running Songbird) but I think that here especially, the devil is in the details.
PS: mentioning Songbird, you refer to quite big numbers here. Since Ubuntu ships Firefox, what does the 42MiB you mention become with proper packaging (i.e. Songbird as a nicely-separated package, using Firefox’s xulrunner and common shared libraries, like Mono and GTK+)? The songbird team never did this because it is _for them_ a hell to maintain for all distros (see the Genesis release notes for more on this: http://wiki.songbirdnest.com/Releases/Genesis/Make_it_Easy_to_Install_Songbird_on_Ubuntu) but it’s Ubuntu’s job, isn’t it? Remains the problem of its memory use and the additional interdependencies, OK, but I’m not sure about the disk usage you gave.
My two cents.
–ronj
[Reply]
directhex Reply:
April 20th, 2009 at 10:37 pm
I’ve already made my Banshee contact aware of issues I expect, including importing of Rhythmbox data (already taken care of in SVN, apparently). So you’re absolutely right – I’m just one step ahead of you 😉
As for Songbird, my understanding from previous discussions (I try not to bother the Ubuntu Mozilla team too much), is that Xulrunner in Songbird is pretty badly forked, so it can’t share with Firefox. Hence it needs its private copy, hence the big size. It’s not “just” a Xul UI like, say, Instantbird or Chatzilla.
[Reply]
[…] “Fitting the Kitchen Sink into a CD” Jo from the the Debian/Ubuntu Mono developers and describes how the way they have split Mono on […]
Any of you guys who think Mono is a trap are ignorant. There are “potential patent issues” all throughout the free software stack. It is safest to just use Windows. Is that what you do? Do you ever play mp3s?
Mono is a superb development tool and runtime that increases the productivity of programmers who use it. The inefficiency of the free software community is the reason why millions of programmers lose to MS’s thousands.
Anyone who pushes continued user-mode work in C and C++ is a cancer.
The performance concerns that are brought up are tiny and irrelevant.
[Reply]
“For the LiveCD you can use CIL instructions just fine, you do not need to have any code pre-compiled. I doubt very much that people use a “LiveCD” for maximum performance”
Miguel de Icaza. I am not incorrect. Cost of mono is massive 48 megs for the run time. You can run in just JIT in memory. Sorry performance is a major issue particular when trying to use the live cd on older machines. There is no saving if livecd has JIT cache enabled it will be eating into the all important ramdisk. Using something that introduces another risk of disk construction stuff up is bad form. AOT form with .net still has dependencies on wrappers its not clean optimization suxs. Hopefully llvm integration will allow stand alone AOT to be build using only native parts. The 6 meg saving is nothing compared to the saving of not needing to ship disk with a mono runtime.
Mono runtime is not used on websites so the only reason it there is to run local applications. Java has a place due to online usage mono does not.
“Nothing will beat a hand-tuned assembly piece of code, but it will not be very agile.”
Wrong humans can not optimize code past a particular point due to complexity. Many cases embedded class C java and basic compliers will produce smaller code than the expected path in asm. Great compliers you cannot hand tune better. Gcc is one of the worst performing C compliers out there.
C native binary being large than the asm native binary equal is a sign of complier defect. Why is it a complier defect the complier failed to solve that all that was required was the smaller binary. Easier to write in is no justification for bloat.
Stop using the lie that just because .net is a higher level language it is entitled to use more disk space and cpu time. Its just the same line as C is allowed to be larger what is also pure lie. There is no need for hand tuned asm. If someone is dumb enough to make asm media player I can see Migual de Icaze using it as marketing for .net. Because .net could be faster due to a human lack of means to optimize.
[Reply]
Miguel de Icaza Reply:
April 21st, 2009 at 1:15 am
@oiaohm,
Running Banshee with my collection of 780 items on my laptop consumes 44 megs, of those 22 megs are shared so the cost of Banshee running with Mono is only 22 megs, not 44 megs.
Now as it turns out the code *generated* by Mono dynamically, that is the code that can not be shared by the kernel or backed by the file backing store is 1.7 megs, to run the experiment yourself, do:
MONO_OPTIONS=–stats banshee-1
That will print this:
Native code size: 1538036
[…]
Total code space allocated : 1703936
The above shows that from the 22 megs of unshared space, merely 1.7, less than 10% can be attributed to the JITed code. AOT compilation or LLVM-batch compilation would at *best* reduce that size in case of low-memory conditions by throwing those pages out to disk.
The rest (which is presumably data) would have to be stored in swap space or not swapped out at all.
So once again, actual data and actual measurements explain a lot more than wild speculation based on the cursory reading of some textbooks.
Miguel.
[Reply]
oiaohm Reply:
April 21st, 2009 at 3:52 am
LLVM AOT or AOT is need on livecd for the simple fact you don’t have swapspace you run out of ram things are going to break. Linux kernel does not send parts it loaded from disk in a native disk to swapspace. It just deallocates and reloads from disk at a latter time no swapspace requirement.
LLVM into memory still gives the problem of not free able memory because simple fact the LLVM generated would not be on disk. Livecd again disk is read only you cannot write it after the fact. Everything has to be got right in advance with livecds. If something might need to be freed from memory you have to design that in.
Livecd you have to presume low memory conditions. Livecd you also have the cost of the disk space for the run time environment ie 48 megs. AOT if it don’t depend on the development environment stuff that is not native. Just like C programs don’t depend on header files or .a files being installed to work diskspace usage will be reduced allowing more applications on the livecd.
Comparing the two media players in there native binary form what is the optimized form for a livecd and choosing the smaller I would not have a problem with. Choosing the bytecode version that need a runtime that is going to create more not releasable memory for a livecd is a very big don’t.
Even on my desktop machine I use all its ram and most of its swapspace doing 3d renders from time to time. Mono usage of ram goes against Linux memory effectiveness.
Ok 1 platform bytecode seams like a good idea. Rebuilt to native code on install would allow Linux kernel great memory management to work reducing need to write so reducing wear and tear on media and risks of OOM Killer. Current way .net programs are installing on Linux are interfering with what the Linux kernel is designed to offer. Current issue all forms of JIT are really counter how Linux kernel is designed to operate.
[Reply]
Miguel de Icaza Reply:
April 21st, 2009 at 4:11 pm
@oiaohm,
You have already mentioned that JITed code can not be swapped out, and I already pointed out that in the case of Banshee (44 megs resident; 22 megs unique, ie, nom-shared; 1.7 megs JITed code that is 3.8% of the total memory usage) it is pretty much noise.
AOT code or any other form of static code tends to consume more space as the instructions are not as dense as CIL instructions. Native compilations using GCC or LLVM or Mono’s AOT will not only make the code larger on disk but also have a larger footprint in memory as you end up loading an entire page of code when you probably only need a few bytes for a routine. Both SGI’s papers and Nat’s GNU Rope paper come to the conclusion that 30% of memory in standard C/C++ applications could be eliminated if the functions were reordered to avoid this problem.
But nobody does the reordering of code today because it is a cumbersome process.
JITed code on the other hand only allocates pages for code that are actually used.
So from this specific use case, we have 1.7 megs of memory that can not be discarded at any time by the kernel (that 3.8% of memory used) but an alternative will end up paying a higher price for bringing into memory swappable pages that contain on average 70% of useful code, 30% of baggage.
You seem to like the theory of how the kernel works and how things should work. And in theory, theory and practice are the same, but in practice, they are not.
oiaohm Reply:
April 23rd, 2009 at 2:28 am
Nobody reorder code where have you been. http://msdn.microsoft.com/en-us/library/e7k32f4k(VS.80).aspx MSVC has profile guided optimization that does exactly what the SGI and the GNU Rope paper talks about. Pgroup complier also has the same feature. So basically Mono AOT is just as crap as GCC and LLVM on full program optimization. No one has bothered doing it with open source compliers. Commercial compliers do it.
JIT advantage more often than not is complier defects nothing more. So lets not fix them. Lets use JIT and depend on a stack of defective parts and put our head in the sand. Sorry I don’t agree with that.
This is what I am getting at there is a 30+ percent memory reduction on offer if the GCC complier is fixed. LLVM already saves some with Link time optimization. If every native program could be rebuilt with LLVM with its link time optimization speed and memory usage would be improved but that is not max. Profile based optimizations lacking is the very reason why JIT can get faster and appear to use less memory. Real fact is most of the time JIT is consuming more when its put head to head with well built commercial compliers.
Simple problem here I know how the Linux kernel should work. I know exactly where the problem is. People like you going on the lazy path. We don’t have to make our complier work right. Make up myth lines that nobody is doing it is another problem. The truth is nobody in your project is bothering doing it. Not that nobody is doing it. Don’t try to hide behind myths with me. Facts of what exists completely disagree with how impossible getting that 30 percent is. Its simple if the complier support getting it.
Now AOT combined with runtime profiling provides something you JIT thinking people forget. Every time a JIT starts up it goes back to starting location on optimization. Yep for a while JIT itself is wasteful. You also have the same problem in theory JIT is a solve all. In operation its a lemon. When JIT has run for a long time it end up at ideal optimization. You stop it restart you are back to starting again.
AOT with runtime profiling since it saves to disk when you get to ideal optimization you start off exactly from that location. On top with AOT more memory can be freed. There is no valid place for JIT other than for the likes of web plugins even then its iffy.
With a focus on memory how much more of Banshees 22 megs unique could be reduced. Programmers don’t think about these things. Some commercial compliers do with modes to reduce unique page allocations at the cost of disk space.
Funny thing is JIT shoved to swap is expensive. It has to be written and read from swap. Compared to AOT where it only needs to be read. The issue is under heavy pressure JIT have caused crashes. Freeing and reusing is a far faster process. If you need ram asp what operation would you want to perform. Copy ram to swap(you have to wait for this) or just write over the block. Reading back is going to cost the same either way.
1 or 2 megs here and there do add up. Does not matter that is only 3.8 percent. If you need 1 extra block not to activate oom killer do you care if that 1 extra block come from 3.8 percent of the memory used by an application. Yes no one should care about the percentage. Wasteful allocation is Wasteful allocation.
Miguel de Icaza Reply:
April 23rd, 2009 at 7:50 pm
@oiaohm,
I am starting to believe that your reading comprehension skills are as good as your writing skills.
Nobody is obviously in the context of Linux, I am not sure where you got the idea that we were talking about Windows. And I know for *sure* that people do that because I am the one that brought up SGI’s cord into the discussion. You just can not read plain English.
You are also showing your ignorance about GCC when you claim that “No one has bothered doing it with open source compliers.” as GCC already supports this profile based optimization and has for years. When I say that nobody bother to do it is because it requires actual runs of the actual code in an actual environment to produce the profile data first (what SGI used pixie for) and then feeding this information into the linker stage in a second pass (what SGI did with chord).
Pixie/cord or the GCC toolchain (read the man/info pages before you stick your foot in your mouth again; You claim to know a lot about these things and yet, it is me, *today* that has to bring this trivial fact to you) both have the above described downsides. They are a pain to setup for people producing the final binaries and this is why *effectively* nobody does it. Not on Linux, not on Windows. It is just too much trouble.
Anyways, in your poorly crafted reply you managed to miss the point that you keep on missing, which is that static code would likely consume more runtime memory on a LiveCD than JITing does.
The rest of your rant is as incoherent as everything else you have produced, and there is little point in continuing this debate.
I stand by my previous facts: you have managed to gather a lot of disconnected bits of information but you do not know how these piece fit together so you keep sounding like an idiot. And Googling your nickname found a number of very funny threads where people have made a sport out of mocking your ignorance.
Miguel
oiaohm Reply:
April 25th, 2009 at 1:22 pm
Gcc does not do it whole executable very well at all. It lacks link time optimization so functions that should have been solved out are not. 30 percent recovery is stuffed up by the Gcc bloat of non solved out functions leading to way more complex code paths to try to make work so it never can get to ideal. Gcc code bloat makes it pointless. If you had bothered trying to use gcc profile based optimization and compared it to all other compliers you would have found out its broken.
Badly broken 7% saving you would call good work with current day gcc using its profile based optimization. Sad part is gcc profile based optimization can end up costing 15 percent more from incorrect duplication of functions as gcc desperately tries to make over complex code paths work and be memory effective.
Same code put though pgroup complier on Linux you will pull out about 25% memory usage of the 30% before you even get to the profiling stage. Due to the same kinds of path prediction llvm should be able to do that it currently does not do for the linking stage. Pre weighting of functions working out what functions should be near what other functions that alone can cut the waste by about 25 percent. Basically your ignorance of what state gcc is in shocking for a so called leader. Good compliers can get the 30 percent without much time running the executable. Most of the running of the executable is normally covered by quality control. Ok lot of open source programs don’t bother with that either.
Bad compliers like gcc trying to use profile based optimization can send you backwards.
In SGI time there was no option bar to run the executable. If you take a close look at SGI document notice the functions they moved around. Lot are purely based on predictable code path. No runtime processing required produce code path and move code blocks to the be the closet to there call location. Tech has gone way forward since then. Your reference documents are stone age Migual more careful reading of them would have shown you that over 20 percent improvement was inside reach without ever needing to run the program.
Mozilla does it on firefox and thunderbird for Windows on MSVC. Not for gcc simple reason it don’t work. No one has bothered to doing the work so it works right. Your idea that no one bothers is so far wrong it not funny. No one bothers on defective compliers. You are major-ally flawed on the nobody bother to do it
Consume more runtime depends on what memory you are measuring. If you are measuring non releasable memory no way more AOT the JIT will always be greater.. If you are measuring total memory yes maybe more AOT. When it comes to running out of memory the critical stuff is the non releasable. The point you keep on missing type of memory used is critical.
Now why in earth cannot profiling of a executable that is AOT not be done like a JIT. Answer is no reason other than lack of will to do it.
Its failure to see the correct answer is not pure JIT and not pure AOT. Its a hybred. Hybrid provides the AOT storage on disk of the binary code so it can be release. Profiling and correcting while running cuts memory usage of AOT. Storage back to disk means next profiling run starts off where you left off anything that does not need alteration because code order is fine gets left as releasable memory. Even on a livecd were the disk is not writable AOT Hybrid can remain ahead on memory usage to any pure JIT system. Reason more will always be releasable.
Unlike normal profiling runs where you have to do it all up front a hybrid can built up it profiling runs over time.
Focus has to return to AOT.
Problem is I see how the parts fit. Putting them in order on page I have trouble with.
Foo bar. Reply:
April 27th, 2009 at 3:55 pm
@oiaohm,
You have problems putting a sentence together, no surprise you have problems with the rest.
I also missed another thing. Miguel de Icaze has over looked completely for a livecd how Linux runs its memory. Native binarys are mapped to memory so under memory pressure the memory can be just freed and re got from disk as need. AOT is a requirement for a Livecd not just optional so Linux kernel can make better use of the ram at hand.
JIT produced ones asm is in memory blocks that can be sent to swap. Problem here Livecd don’t have swap so under memory pressure Linux cannot free those blocks in a nice way. Lot of .net application will risk forcing the Linux kernel to perform a OOM killer operation. Not what user wants. Is 1 or 2 extra applications worth user having there programs terminated halfway more often. You really have not priced what you are doing.
Pure byte code interpreter you might be using enough .net applications to save space since pure bytecode can be mapped to memory like native you might be saving memory and bytecode interpreter engine can also be mapped to memory. Performance is going sux really bad.
Basically no point having a kitchen sink if it don’t fit in the kitchen. This is the problem .net is too big for kitchen(ram).
[Reply]
Anyone using a live cd for ‘maximum performance’ is an idiot. The bottleneck isn’t how much ram you have or how fast your CPU is, it’s how slow your CD-ROM drive is. The first thing I do when I start my computer is launch FF and thunderbird at the same time. All the CPU in the world won’t make that any faster on a live CD.
[Reply]
How slow you CD-ROM is on factor. Out of ram is another. Disk compression is another. Use of memory stacking is another.
Surprisingly compressed cdrom in a 52x cdrom drive is not far behind a harddrive not compressed in read speed.
Running out of ram is a real performance killer. Particularly when it gives the Linux kernel no other option to pick an application and kill it to recover memory. Maximum performance means getting everything right for the hardware at hand.
Ram CPU and Disk usage are all factors. .Net busts ram and cpu. Poor grade of gcc optimizations is busting Disk and CPU. Hitting Disk and CPU machine keeps applications running ok slowly. Hit ram then you have application terminations.
So you call Linux kernel picking applications at kind random to terminate not a performance killer?
[Reply]
alphaomega Reply:
April 21st, 2009 at 5:13 am
@oiaohm, You sound pretty desperate to push the idea that Mono isn’t good enough. When you have to nitpick, you’ve already lost. A LiveCD is just a way to give the Linux distro a try without having to do potentially dangerous partitioning. The only other use for a LiveCD is as a rescue disk. People do not run real desktops on LiveCDs, so your complaints are pathetic at best and retarded at worst.
Running OpenOffice of Firefox is far more likely to cause the system to run out of memory than any Mono app, but I don’t see you complaining about those.
You are very clearly one of those BoycottNovell trolls who only bash Mono because it’s a Novell project and has no real technical reason for not using it, so you try and construct theoretical reasons for badmouthing it.
Grow up and get a life.
[Reply]
oiaohm Reply:
April 21st, 2009 at 9:40 am
Have you not read. I never said OpenOffice and Firefox was good either. Yes I have placed complaints about them in the past too. Both are bloated more than they should be.
I have zero tolerance for bloat. Long term you have to address the technical problem. I have said this is a defect of any JIT. I would be ripping into anyone with the idea of placing a Java based media player as well.
Novell is not the issue. Its a technical problem. Using a methods not compatible with Linux memory management do cause problems. OpenOffice is one of the worse offenders by there usage of java. Firefox has many causes of its problems.
This tolerance to bloat at some point enough is enough.
Besides MS .net is sneaky it does AOT really. Hides cache of the past run in the EXE. This is no suitable were disk space is limited. Mono with JIT went away from how MS did .Net as well. There are very good reasons only to do JIT when there is no other option. MS designers of .NET are aware of this.
It about time for the mono project to turn its focus to native. MSVC can do hotspot style optimizations for AOT by profiling executable runs. There is a simple fact here. native binaries are a bytecode. Every optimization that can be performed on a .net bytecode in a JIT could also be performed on a program as a native binary. So hotspot performance boosting could be done for everything.
Focus on the wrong thing. Forget JIT focus on AOT. No more hate from me. Making AOT work to its best also means returning focus to the optimizations of the libraries you depend on.
Put focus in right place. Anti-bloat in all projects. Design errors need to be removed.
Have you even done the maths of the problem I am talking about for 200 users sharing a server. As a AOT media players main executable costs 1.5 megs in memory as a JIT cost is 300 megs. JIT don’t scale same reason why it cannot be pushed out of memory causes extra memory to be allocated. Its pure bloat. Linux kernel is purely designed to prevent native programs from causing this kind of bloat.
I am not singling mono out. People building these livecd’s need to start taking this on board. Anything that screws up a livecd also causes when you have multi-able users to eat more memory.
[Reply]
Miguel de Icazq Reply:
April 21st, 2009 at 4:28 pm
@oiaohm,
You seem to be a purist, and I respect that, but you seem to be drowning in a glass of water.
There is a large difference between “Banshee on the LiveCD” and “Banshee used by 200 people on a server”.
I have already explained the LiveCD scenario, where at most 3.8% of memory is used by JITed code in the Banshee run and considering that a statically compiled piece of code might bring 30% of unused code the benefits of static compilation at this point are dubious.
The good news is that it can be measured.
The second scenario, running Banshee with 200 users on a server is kind of useless as I do not really see 200 people running Banshee on a single host or plugging 200 headphones into the server. But let us assume that it is not Banshee, but some other piece of software, let us call it “Funguinator”.
So the Funguinator willc onsume 1.7 megs of code if JITed, and that multipled by 200 would be 340 megs of JITed code. A lot of code for some, but we are assuming that you are running the Funguinator on a 1999 Dell Pentium in the middle of Africa. In this case, the administrator for the Funguinator who is commuting every day taking the Bus Route #45 from Mombasa to Lembeni has some hours to kill on the bus to think about a breakthrough idea for his 200 users.
To reduce his memory consumption of 340 megs for his 200 users he will run:
mono –aot …
On each one of the assemblies loaded. This will reduce the memory usage for the Funguinator to something more manageable.
The “extra” unused code that for a single application was at 30% is not as statistically significant when you have your 200 users, and they will likely be touching more pieces of the code than regular users would use.
So the bottom line is: for a LiveCD using JITed code is just fine and likely would consume *less* memory than precompiled code due to regular waste. The 200 users on a server running 200 instances of the same program will be able to reduce their memory usage using the tools available.
But it is also worth pointing out that running around waving your arms claiming that the sky is falling is not very useful if you have not actually measured how fast the sky is falling.
Miguel
oiaohm Reply:
April 22nd, 2009 at 3:20 am
Miguel. Again the point here is not that it is just 1 application. What was the major issue with Java Looking glass desktop livecd. Memory JIT has the same negative effect.
Lets say one day the complete desktop is replaced with mono JIT run applications. Don’t put our head in the sand here. That is what a lot of .Net people would like.
JIT cannot be swapped on a livecd. Cannot be freed. Basically the more you get the bigger your problems become. This person is not talking at stopping at 1 or 2 .net applications. So yes you could have 20,100,200…. application in future all consuming memory in a non releasable way. 200 users or 200 applications it really makes no difference.
So AOT is 30 percent bigger. If so then this case the media player is not really smaller. Its nothing more than a trick. Lose the means to free up memory in exchange for slightly smaller disk usage. More this is done sooner or latter maker of livecd will have to switch to AOT so disk can work. End result livecd will have to lose applications. Its better not to add applications that users will expect in future if you will have to remove them.
You could always use like UPX on the native binary and compress it by the same amount again you don’t do this on a livecd lack of swap and UPX also makes native binary unable to be released from memory. Disk size is not the issue.
Native binary compared to JIT is comparing apples with oranges. Both have completely different memory effects. Native binary to AOT is fair and JIT compared to UPX compressed binaries is also fair both have the same memory effect. The compare for disk usage is simply wrong stop trying to defend it Miguel.
Preallocation in applications so applications can free there memory for other applications to use is not without its price.
Simple point here Miguel. You are saying measure 1 application. You are not thinking like me. Over time you will get more and more applications doing the same thing. Get it right now future problem does not happen.
Miguel de Icaza Reply:
April 23rd, 2009 at 7:54 pm
@oiaohm,
The entire scenario depends on the JIT case for the LiveCD where there is no disk space available for AOTed assemblies.
If you are really concerned about the memory usage in your system, and want to maximize code that can be thrown away by the kernel, all you have to do is run this command:
cd /usr/lib/mono/
for i in `find . -name ‘*.dll’ -o -name ‘*.exe’`; do mono –aot $i; done
And you have an AOT system where the kernel can throw out all the code that you need.
oiaohm Reply:
April 25th, 2009 at 1:46 pm
LiveCD have block device compression. Diskspace used is not raw executable size either.
Measurements here completely have been wrong. AOT that happens to compress more than the bytecode can happen even of the AOT is larger.
The person who started this did none of there maths right and you are defending them. zisofs was created for exactly that reason. Problem here blocks on zisofs still can be kicked out of memory where JIT cannot.
If measurements were right person might have case. Measurements wrong person needs to be kicked. AOT and Bytecode has to be compared. Compressed state of both AOT and bytecode also has to be compared. Can you predict with 100 percent that AOT will be still be larger on disk after compression.
The cost of the engine on livecd diskspace also has to be compared. If mono is not needed for anything else there is 48 megs of disk-space to be freed. So AOT costing 8 megs more for 3 programs you are still ahead when not having mono on the livecd if you only have 3 .net programs on there.
You are very quick to say no diskspace. How much no diskspace. If AOT is larger than the native code executable and I am trying to make a livecd to run on limited ram like 64 megs every locked up bit counts AOT will lose so will JIT end up going native c++ program.
When was the last time you build a livecd Migual and when threw everything that is required. Its quite simple really. Real sizes on livecd is important so size after compression for JIT stuff runtime has to be weight up. Memory usage important most important is amount of non freeable. Higher the amount of non freeable higher the amount of min ram for livecd to operate.
Person here as done a really poor compare. There are a lot of things that must be run before making a judgment call for a item for a livecd.
AOT, c++ and C programs win a lot in the compares. More often due to numbers of programs using the JIT cost of the engine to run a JIT on a livecd and out weight the cost of slightly bigger executables on disk.
oiaohm Reply:
April 26th, 2009 at 12:50 am
Besides mono aot I know sends code size on disk way backwards. Major cause is so simple its not funny. Its items like GTK# its a wrapper in AOT mode its not optimized out of existence. This is where Miguel instruction to convert all .dll to aot is so badly wrong many of those dll should cease to exist from AOT applications. Thank you for a wasteful design Miguel. Same defect exists in GCC as well.
There are major problem in the core of Mono design when it comes to AOT. Time to pull end out sand and see them.
Long term mono defects could disappear if people look and see. I was aiming to find out here if Miguel had eye on ball to where problems in mono was and would be truthful about them. Answer is no Miguel. Miguel would mind answering how long before mono gets called Microsoft mono just like moonlight is called today. Then how long before Microsoft starts trying to charge for mono usage.
All the talk about Linux not getting left behind from Miguel really means nothing. Linux is way behind in complier tech. .Net is not helping the issue. Mono threatens Linux distributions means to operate in low memory systems. This would be great for Microsoft low memory systems is what keeps Linux in the netbook market. The time of the always growing hardware ended a few years ago. We have to learn to live with what we have. 1ghz processes and 256 megs of ram.
Miguel what side are you on. Problem here is if a true optimizing AOT is made .net applications will be producable without any dependence on mono being installed. This should be seen as the goal. Once .net is turned to a pure native binary cures most of the shipping issue. Neither Microsoft or Novell would gain from this. Resources usage would gain from this.
The line I am covering is also providing a fall back solution for Linux so .net application can always been used even if its build to binary then shipped back from a country that software patents don’t apply. AOT is key to long term safety of .Net. A distribution with all .net applications built native and no mono should be possible. Just like you can have a distribution built with gcc and no gcc installed. Also like .la for dynamic libs. You don’t need the .la installed when C program is using .so file its only used in linking stage. Lot of .dll in mono should be reduced to nothing more than .la files at worst in AOT mode. .la files don’t optimizes with gcc either portland group complier does optimize .la files. Failure to tag the reduce able .dll out of existence different to the non reduce able is a major problem for cutting .net back to min disksize.
So far Miguel defense says Microsoft or over looked key defects. What one are you Miguel. I was expecting you to come out and say Mono has the following defects this is why AOT is useless at this stage. Instead you started trying to make cover story that annoys the hell out of me.
No program is perfect hiding defects is not something a project lead should ever be doing. Blocks them from being fixed.
i disagree with most things said! but then again who am i to decide, some good points taken though 🙂
[Reply]
Banshee just needs to offer uPNP services on par with RB and then it will be a solid candidate. uPNP is a big deal. I do realize uPNP is being worked on in Banshee.
[Reply]
Don’t listen to oiaohm, he’s full of shit. All he does is post incomprehensible garbage and argues over things he has no understanding of (he’s arguing about Mono’s runtime performance with Miguel ffs).
[Reply]
oiaohm Reply:
April 21st, 2009 at 10:29 am
Miguel de Icaza is agreeing with my calls. Linux Hater’s Blog Regular.
This should tell you something. There is only 1 best possible outcome. Everyone can overlook a problem. Its not that I am Full of Shit. It is you guys in Linux Hater’s Blog who are.
Everyone has simple forgot about a livecd lack of swapspace. This does alter how things should be built. Preallocation on disk of items that would normally go to swap is required. Same with when you are running 200+ users also forces same restriction unless you want to put insane amounts of memory in the machine. Its really simple to focus on disk space used and forget about memory and cpu usage.
Most likely this idea of preallocating is to advanced for low minded people from Linux Hater’s Blog.
[Reply]
Miguel de Icaza Reply:
April 21st, 2009 at 4:39 pm
@oiaohm,
I do not agree with you Mr Oiaohm.
You seem to have collected a series of disconnected facts, but you do not have the experience to know how things fit together.
Hence I posted before “In theory, theory and practice are the same, in practice they are not”. And you are a theoretician because you have educated yourself in various technology tidbits, but there is a very big difference between having a high-level overview of a problem and getting your hands dirty and understanding the problem.
One of the most brilliant developers I have ever met was a 16 year old kid that at the time had some experience, not a lot of theory, but was willing to get his hands dirty. He grew up to be one of the best developers in the world. With a great sense of “thin-slicing” for all things performance and scalability related, something that no amount of reading, debating or discussion on the forums will give you. He sat down, measured, tweaked and improved.
You on the other hand have a lot of opinions based on things you have read. But opinions are like assholes. Everyone has one. The difference is that some opinions carry more weight than others based on their reputation and at least in my eyes, and based on your comments, your skills do not match the level of your opinions.
[Reply]
Christoph Reply:
April 21st, 2009 at 8:41 pm
@Miguel de Icaza,
I like this one! This was deep really. And I must admit that I also have to get my hands dirty more often. I read a lot and know a lot *theoretically* but I need to get my hands dirty more often. I really like this comment. There is a lot of truth in it.
oiaohm Reply:
April 25th, 2009 at 2:18 pm
Problem here is I have built a lot of livecd and embedded items. Nothing is more hell than PPC chips with no ram at all. I have run systems with lots of users. Seen the effects as well.
Idea that that my opinions are without testing is wrong. The effects of what you are doing Miguel have been documented over and over again. Just everyone puts there head in sand. Ok project looking glass livecd needing 4 times the amount of ram it should have to operate. Yes you can take it cut is ram requirement by 1/4 just by converting it to AOT. Disk compression required of course to make it fit. Funny part is amount of data loaded off disk is larger. Kernel free-able memory does not hurt much particularly when the livecd is compressed.
Simple fact here Miguel you have not done the compares on livecd’s to know the idea that non releasable memory is priceless is a foolish answer on a livecd. Its costly to the min requirements for the disk to work. There are other things you can do about disk-space usage. Compression is 1. Profiling of executables is 2. Using a better complier or complier options is 3. There is a build for size option in all compliers. None have been done in this test. So why should a invalid compare be trusted. Lets take the default built program from repo and size it. Problem default base program from repo is built for speed not size also built for most free able memory.
Default repo is built with gcc that basically cannot size optimize an executable ever. There are problems here no point claiming this is better than putting head in sand about other problems.
Problem here Miguel you are making comments on a item you don’t produce have not been producing so making very bad judgment call. You don’t know the list of what must be checked to make a good livecd. Neither did the person doing the compare.
[…] http://www2.apebox.org/wordpress/rants/74/ Added my own thoughs on mono to that one. People really don’t think mono though. Its pure crap techincally. […]
[…] http://www2.apebox.org/wordpress/rants/74/ Added my own thoughs on mono to that one. People really don’t think mono though. Its pure crap techincally. […]
How does Banshee hold up in the error cases compared to Rhythmbox these days?
Previously, Banshee’s reaction to erroneous data was to barf and die with rather odd errors where RB would swallow and continue. Same with the runtime memory footprint after a while.
I am perfectly capable to believe that it has changed, however I also remember spending three days waiting for Banshee to try and attempt to index my media before deciding that the merciful thing was to take it out behind a shed and shoot it in the head.
[Reply]
Spider Reply:
April 21st, 2009 at 9:15 am
@Spider, Tested further. Banshee still lacks working type-ahead find for browsing, making the keyboard navigation a bit of a pita. Bummer, I thought all the Mono goodies would make that sort of thing easy.
[Reply]
Spider Reply:
April 21st, 2009 at 9:19 am
@Spider, Schmee again.
Checked some more and it also appears that Banshee will happily forgo dmix and lock the alsa device exclusively. Either forcing you into using (known broken on some hardware and software combinations) pulseaudio or simply forgo multiple audio sources.
Yey, completeness. Say that again?
[Reply]
Glitches while decoding flac files ( after approx 2 minutes ) while doing library import/rescan at the same time.
[Reply]
Banshee still dies on id3v2 tags on .mp3 files if the fields contain the “Composer” tag.
Sorry, This player is not mature enough to replace Rhythmbox as default.
[Reply]
“The 6 meg difference could be the first 5% of OpenJDK inclusion. Or it could be two extra languages. Or it could be a cool new tool (Gnome-Do, anyone?).”
My 2 cents: install gnome-backgrounds by default! 🙂
https://bugs.launchpad.net/ubuntu/+source/ubuntu-meta/+bug/311389
https://blueprints.launchpad.net/ubuntu/+spec/gnome-backgrounds-as-default
[Reply]
[…] over patents where its de facto standards — such as FAT or .NET — are used. Only a “box of monos” (pun intended) would consider Mono to be a Good Idea™. As a team, the Debian Mono Group (which […]
[…] over patents where its de facto standards — such as FAT or .NET — are used. Only a “box of monos” (pun intended) would consider Mono to be a Good Idea™. As a team, the Debian Mono Group (which […]
Microsoft has only granted immunity to Novell users/clients, and Mono’s GPL does not cover Mono’s Windows compatibility stack – of which TomBoy uses extensively. There is a lot to be wary of from MS when using Mono’s Windows compatibility stack, and IMHO thus lots to be wary of from TomBoy.
[Reply]
directhex Reply:
April 21st, 2009 at 1:51 pm
@Jason, quantify your statement. “Windows compatibility stack”? What does “uses extensively” mean?
[Reply]
alphaomega Reply:
April 21st, 2009 at 2:19 pm
@directhex, He’s confused. He no doubt thinks that Gtk# is Windows.forms.
[Reply]
alphaomega Reply:
April 21st, 2009 at 2:18 pm
@Jason, You said the same thing on Sandy Armstrong’s blog and yet are so obviously full of bologna that it’s laughable at best. Do you even know anything about what parts of Mono Tomboy uses? Because it sure doesn’t use any “Windows compatibility stack”. It uses corlib and Gtk# and some Mono extensions, but it does not use Windows.Forms like you are trying to suggest.
[Reply]
I totally agree with Spider. Rhythmbox may do less in some cases (although it does more in others — automatic library update is one thing that Banshee still doesn’t do) and also has less bling, but at least it does what it does (like, at least it doesn’t try to do video*).
* Watching videos with Banshee has been interesting for me — I generally only get sound. This may partly be the fault of my graphics driver, don’t know, but Totem, VLC etc. all work.
[Reply]
directhex Reply:
April 21st, 2009 at 3:40 pm
@Apron, Video is an interesting one. The issues you’ve had are quite possibly driver-related (I’ve had random issues in some players before on my laptop). A video jukebox is a significant time investment, as so few video file formats come with the rich ID3-style metadata that makes using a music library worthwhile (so you need to add the metadata yourself on a per-file per-app-database basis).
Spider sounds like he should file some bugs upstream
[Reply]
I have a hypothetical question:
Lets assume that the open source world adopts Mono entirely. Microsoft doesn’t sue over patents. No more arguments and all new projects are written in .NET code.
Is this something we would want? The majority of FOSS created with a Microsoft technology? Plus, you then have Steve Ballmer bragging that Linux has adopted .NET, which gives him fuel to belittle GNU/Linux.
I just don’t understand how this would be a good direction for FOSS.
I’ve tried to see it from Miguel’s and the Mono developer’s point of view, but it still doesn’t make sense to me.
[Reply]
directhex Reply:
April 21st, 2009 at 4:39 pm
@Johnny Utah, see: http://www2.apebox.org/wordpress/rants/70/
[Reply]
Johnny Utah Reply:
April 21st, 2009 at 5:09 pm
@directhex,
Great post and I see the point being made. I believe its a shame that the open source community has become so divided over the Mono project. It makes me wonder if certain anti-Linux companies are sitting back and laughing.
[Reply]
On the same media library, Banshee was using 2x the ram at runtime for some reason. Maybe Intrepids version is outdated?
[Reply]
Eh, keep in mind that Microsoft & HP are giving out royalty-free licenses for C# implementation (not .NET) as long as it’s an ECMA standard. ECMA drops them (although after like 10 years or so.).
Would be great if there was a resource that clearly explained this situation.
[Reply]
Banshee really isn’t very good, and I would recommend dumping it. I’d also recommend dumping Totem, again it’s really not that good.
Instead VLC should be used as a replacement for both. It also has the advantage of being available for multiple platforms. I use VLC as my standard media player on all my computers, running OSX, Linux, and Windows XP, and quite frankly it’s a hell of a lot better choice than either Totem or Banshee.
Wayne
[Reply]
directhex Reply:
April 21st, 2009 at 6:12 pm
@Wayne, There are issues in including VLC on the install media, which can be boiled down to “codec patents suck”. That’s why GStreamer players are favoured – the player on the CD can trivially be extended with less-than-Free formats without needing to mess around, but be “safe” by default.
[Reply]
Wayne Reply:
May 27th, 2009 at 5:50 am
@directhex,
The “patent” or Intellectual Monopoly issues only exist in certain jurisdictions. Should we rob the users in other jurisdictions of a superior application because a few countries have passed a bad law?
[Reply]
Anders Reply:
July 19th, 2009 at 9:10 pm
@directhex,
So, Patents is a problem with VCL but not with Monolight/Mono?
Strange…
[Reply]
directhex Reply:
July 19th, 2009 at 9:14 pm
@Anders, ACTIVELY ENFORCED patents are a problem. Vague un-enforced patents are common and uninteresting.
http://www.theregister.co.uk/2008/03/07/patent_crackdown_at_cebit/ means “actively enforced”, http://www.microsoft.com/interop/cp/default.mspx means “not actively enforced”
giacomo Reply:
May 26th, 2009 at 7:43 pm
@Wayne, doesn’t it use QT4?
[Reply]
Wayne Reply:
May 27th, 2009 at 5:52 am
@giacomo,
No. I use VLC on E17, Gnome, KDE, and XFCE (the order is alphabetical, not preference). I also use VLC on operating systems which don’t use those desktops, OSX, and god forbid Windows (my boys are WOW addicts).
[Reply]
I think it would be an improvement for Ubuntu if Banshee would replace Rhythmbox. It’s not that we now should all embrace Mono, and rewrite everything in it.
But that’s not the point here. Banshee is currently a better multimedia application — according to _me_ — than Rhythmbox. That, plus the save of some precious space, should be enough. Coincidently Banshee was written in Mono, but that shouldn’t be a reason why we wouldn’t use it.
I don’t dislike Mono, even though I’d like a more-open language where possible (though good projects shouldn’t be left out for that reason if they really are the best), but what I do dislike about it is the, sometimes, blind enthusiasm for Microsoft technologies from the Mono developers. Closed standards are a burden, something we should choose to avoid rather than embrace.
[Reply]
directhex Reply:
April 21st, 2009 at 6:15 pm
@Sense Hofstede, How closed is closed? You can download all 1,109 pages of EMCA 335 and 334 if you like. Apps designed for the Linux desktop, like Banshee or Tomboy, use the standardized parts of .NET plus Free Software embrace/extend technologies like GTK#
[Reply]
Sense Hofstede Reply:
April 21st, 2009 at 6:39 pm
@directhex, using ‘closed’ indeed wasn’t the right word to use. My apologizes. I meant something like ‘locking in’, since the language seems to focus on support the .NET framework rather than innovating themselves.
[Reply]
Reggie Reply:
April 21st, 2009 at 8:12 pm
@Sense Hofstede, Interoperability is a bigger selling point as far as I’m concerned. The ability to be able to take my .NET apps and port them to Linux (either client facing apps or, especially, ASP.NET apps) is much more important needless “innovation”.
Wayne Reply:
May 27th, 2009 at 6:03 am
@Sense Hofstede,
For users who aren’t in an area where patents are an issue, this might be feasible. However with there being a large amount of uncertainty involved as to the risk of Microsoft asserting it’s patents, using anything that’s mono based is not viable, if Ubuntu is to ship in those jurisdictions. There is of course no reason Ubuntu couldn’t be shipped with Mono outside those jurisdictions.
For anyone interested in the legal issues surrounding Mono (and Moonlight), Sam Varghese wrote an excellent article detailing his research into Mono licensing, you can read it at:
http://discuss.itwire.com/viewtopic.php?f=29&t=13604&p=48737#p48613
The issues Sam found in his research means that shipping Mono is more problematic than shipping VLC with it’s built in codecs. This of course does not prevent someone from an area where patents are not an issue from rolling their own variation on Ubuntu with VLC included.
[Reply]
Anders Reply:
July 19th, 2009 at 9:18 pm
@Sense Hofstede,
And according to me, RB is better than Banseen. Get better arguments.
About Banseem
Pro: Save smal ammount of disk space
Con: Not as stable as RB and uses libraries with a questionable (in many ways) patent threat.
Untill Microsoft binds itself to not use it’s patents on Mono/Monolight etc, I would go for RB, as it has no such problems (imaginativ or not).
[Reply]
C# is a programming language and runtime. It is like C or C++, created by AT&T. Who cares who created the language as long as it is good — what matters is the libraries and applications created in it.
Imagine 1,000 applications, all rich, slick, reliable, etc. In my opinion, one of Linux biggest challenges is that while Firefox and OpenOffice are good, the next tier of apps are not up to that level of polish. Betters tools will get them there faster.
Ballmer might get bragging rights that Linux has adopted .Net, but it will come at a huge cost: these free applications would make Windows obsolete. And who cares about “bragging rights?” This is about freedom, right?
[Reply]
Wayne Reply:
May 27th, 2009 at 6:07 am
@KeithCu,
Keith,
Why would you want to use a limited implementation of a programming language designed by a failed company (read Microsoft’s SEC filings for details – and watch how the number of layoffs at Microsoft increase over the next few months)? This doesn’t make any sense at all.
Also why would you want to use something which is legally problematic? Of course if you come from a place where patents aren’t an issue, that’s a different story.
[Reply]
Anders Reply:
July 19th, 2009 at 9:23 pm
@KeithCu,
But the problem is not with the languages as to it’s libraries.
Like C, it’s a nice small language, but a very smal fraction of all C-programs don’t use the standard C librarie. Same with C#, most programs uses Mono/.NET libraries, and they are partly covered by patents by Microsoft. And we really don’t know if those will not be used against Ubuntu/RedHat etc, except for Novell. And according to some posters, it will not cover new versions of .Net.
[Reply]
I hope the 6,1 MB was a bad joke….throw Tomboy and F-spot away and you don’t need Mono on the Live CD anymore and save about 60 MB !!!!! (hm… 10 times of that….)
[Reply]
directhex Reply:
April 21st, 2009 at 8:42 pm
@Mr. Kanister, 54.4 MiB, to be precise. Minus a note-taking app or photo manager app.
But why stop there? Pull OpenOffice.org, save 244.3 MiB. Pull FireFox, save 112.2 MiB. Pull Evolution, save 59.1 MiB. Since you didn’t seem to think replacements for Tomboy/F-Spot were worthwhile, I assume you don’t think replacements for these three are worthwhile either. Right? And if you DO want to replace them, which apps do you propose as alternatives which are 1) smaller 2) at least as featureful and 3) support importing all the same data?
[Reply]
jldugger Reply:
April 22nd, 2009 at 2:26 am
@directhex, because people might actually use firefox with the live CD. Certainly a good way to check on Planet Ubuntu while the installer works its magic. But I have a much harder time believing people honestly use F-Spot to manage photos from a LiveCD environment, same goes for Tomboy. Instead, we could be putting things on the CD that people might actually use without an existing Ubuntu install, like backup recovery.
[Reply]
Apron Reply:
April 22nd, 2009 at 4:21 pm
@jldugger: The live CD serves as a showcase (for what you can do with Ubuntu), too, it’s not just an installation CD with added entertainment or the CD you use for when your Windows installation is broken and as that it needs software that people can play with (even if they won’t import photos) before they install.
oiaohm Reply:
April 25th, 2009 at 2:42 pm
This is why it important to have low ram requirements to operate.
How do you know how bad a person is stuck. Demo disk must operate. Must have the lowest odds of glitch. If it glitches gives user a reason to stay on windows. Better to have a few less applications and work perfectly than more applications and stuff up.
Wayne Reply:
May 27th, 2009 at 6:10 am
@directhex,
I’ll partially agree with you about Evolution, it should be removed from the Gnome Desktop. Integrating Evolution into Gnome, like Internet Exploder is integrated into Windows, was downright silly. An email client is not part of a desktop.
[Reply]
Move all the existing C/C++ code to C#, and with that 600 MB, you could get a lot more functionality in the same amount of space. How many string classes exist in today’s 600 MB? XML parsers? Jpeg / png codecs? cross-platform widgets?
The way to save space is to use more managed code, not less.
[Reply]
Apron Reply:
April 22nd, 2009 at 4:11 pm
@KeithCu: well, I really don’t believe today’s computers (and their users) are quite ready for that. Especially as Linux is always touted as an alternative for old / low-powered computers. Linux’d also be going a way Microsoft themselves didn’t dare to be going with Vista.
[Reply]
oiaohm Reply:
April 25th, 2009 at 2:35 pm
Same mistake KeithCu. Smaller on disk does not equal smaller in ram. If you fit more functionality and don’t have the ram to operate it all the extra functionality is pointless to the person without much ram. Basically everything managed code is going to blow your memory usage. Working under 64 megs of ram will not happen.
Livecd fit way more than 600 megs on a disk. At least 1.2 Gb of executables in fact due to compression. I have seen over to 2.5G of programs fitted into a 600 meg disk using stacking compression in-combination with file compression. Stacking compression matching blocks in different executables in the 1 block on the disk. Does have a performance cost on livecd works great on flash and rom drives. How well the program compresses is also important. How much ram can be freed from the application is also important.
Thinking flash drives are becoming the demo media of today. Better compression can gain you just as much as using managed without the ram cost.
[Reply]
Good timing as it seems Rhythmbox is dying: http://ubuntuforums.org/showthread.php?t=1076064
[Reply]
directhex Reply:
April 22nd, 2009 at 1:06 am
@Jonathan, I think stories of actual death are overstated – but it’s not seeing the most vibrant development of new features ever – i.e. most changes these days are tweaks to existing functions for new APIs, rather than anything new
[Reply]
Anders Reply:
July 19th, 2009 at 9:29 pm
@directhex, which means that RB is mature and don’t need that many new (untested/buggy) features. It already have them in it.
[Reply]
directhex Reply:
July 19th, 2009 at 11:22 pm
@Anders, Yeah, except when it doesn’t.
Would you advocate stopping all development on something you think is “finished”, and ignoring any competition? Guess what, that’s what Microsoft did with IE6.
i lıke banshee
but i dont like the fact we cannot detatch the movie player from the media application.
ı also dont lıke the fact we cant use GENRE searches out of the boxes… ı dont thınk anyone wants to go and create playlısts based on genre.. ıts quıte absurd for a modern medıa player…
[Reply]
It’s very sad to look how mono is being pushed using the most ridiculous reasons.
First, mono opponents were ridiculized pointing out that they were rejecting mono only because its technology came from MS. Now we have to see how mono its being pushed only because its technology comes from MS.
I though that FOSS in general could make its choices just by technical merit, but when someone brings some technical points to the discussion, he is portrayed as being too purist or a fool, a simple mono-hater.
I think that similar technologies existed before .net and mono and they fitted very well in some scenarios, but from there to trying to use them to conquer the desktop and then the whole system, it has been necessary that some megacorp to trademark it and to make alliances for its inclusion everywhere to be found more plausible.
I dont think mono is the way for achieving EVERYTHING, as it seems to be preached time after time. Turning FOSS environments into some megacorps-backed technologies marketplace and battlefield is something that we should avoid at any cost.
Please don’t laugh at people just for saying that what is good with mono, can be much better without it.
[Reply]
vslee Reply:
April 23rd, 2009 at 4:17 am
@brd, am I missing something here? The arguments seem to be:
OP: lets replace RB w/ Banshee because of technical reasons (size, functionality, speed of dev, etc…)
A select few: nooooo…. mono is based on something invented by the evil MS! Choose something else or else I refuse to use Ubuntu anymore!
Can you point to where anyone’s saying: hey, lets choose Banshee just because, you know, it’s somehow related to MS…?
I think the dismissal of the FUD commenters is pretty fair because they don’t bring many valid technical arguments to the table. It’s mostly just – ah patents! (conveniently ignoring the same issues that might apply with Linux, Java, Python, etc…)
[Reply]
brd Reply:
April 23rd, 2009 at 4:54 pm
@vslee, I see too many pseudo-technical reasons to explain a phenomenon that can be explained by just one fact alone (Occam’s Razor):
Novell is pushing his Mono, through his Banshee, his F-spot and whatever other thing to come that depends on mono and fakes to be part of the standard Gnome Desktop, to take advantage of his agreement with Microsoft over his competitors as sooner as possible.
[Reply]
I’ll be moving off of Debian/Ubuntu if mono is present in their distributions at the 10.04 releases.
The patent contamination may have made it moot by then anyway when MS sues to extract money.
[Reply]
directhex Reply:
April 22nd, 2009 at 10:52 pm
@Rex, g’night then, y’all. Don’t let the door hit you on the way out.
[Reply]
Wayne Reply:
May 27th, 2009 at 6:20 am
@directhex,
Why shouldn’t Rex “leave” if he doesn’t like Mono? Isn’t Free Software about choice? Many of us chose to dump OpenSUSE when Novell signed their deal with Microsoft. It was my choice to get rid of OpenSUSE on the one machine that was running it, and I stopped recommending OpenSUSE. I’ve probably cost Novell a fair bit of money since the deal was signed.
I don’t like the direction Ubuntu is taking with Mono, which is why my personal computer runs Moon OS (a Ubuntu spinoff using Enlightenment). Until Canonical stops using Mono in Ubuntu, I will be recommending other distros.
[Reply]
@Rex:
> I’ll be moving off of Debian/Ubuntu if mono is present in their distributions at the 10.04 releases.
I’ll be moving **to** Debian/Ubuntu if mono is present.
There! One user lost, one gained + great technology stack gained (which will mean more users in the long run).
I wonder what percentage of *nix users are emo kids, living in their parents basement …
> The patent contamination may have made it moot by then anyway when MS sues to extract money.
Sue who? Novel? Canonical? Ubuntu? the developers? Microsoft can sue thin air and have better chances of getting money out of it …
How can you sue open source software and get money of it?
As bad as it is, Microsoft has a history of not using patents aggressively only defensively. There’s no precedent showing Microsoft will sue, and specifically sue Mono. Besides why would they on one hand aid the Mono team with test suites and support and sue them on the other hand ? They would take a huge PR hit if they ever sue Mono which is product based on standardized specification (which they made). The day Microsoft sues Mono or Mono users, it will be a *great* day for free software, as the trust Microsoft has from it’s customers will completely shatter, it will mean self destruction.
[Reply]
oiaohm Reply:
April 26th, 2009 at 1:35 am
Sorry Pop Catalin. Tomtom case was MS offensive. Microsoft uses there patent aggressively. Normally against targets that are presumed to be weak.
Open Source software. The sue list is as follows from the MS play book.
1 Sue the device Maker.
2 Sue the Distributor without approval.
End users and developers get used to force Distributions and device makers to support it so MS can sue them. As a developer or a user you are nothing more than a pawn in this game.
By mono license to avoid license risk every machine you have would have to get mono direct from novell.
[Reply]
alphaomega Reply:
April 30th, 2009 at 1:03 pm
@oiaohm, TomTom took the risk of not paying for a FAT license even though they knew full-well that they were infringing on the FAT patents. It is no secret that Microsoft has been licensing FAT for years. TomTom decided to intentionally infringe the patents, and they got caught at it. Boo hoo.
All TomTom had to do to be safe was drop the FAT module from their Linux kernel and use something else. In the end, they probably settled for $250,000 (the ‘infinite units sold’ license cost for FAT) if even that much.
The people badmouthing Mono and saying the world will end because Mono implements Windows.Forms obviously haven’t engaged their brains since 10000 BC. Like FAT, Mono users can simply choose not to use Windows.Forms if it is ever found that their Windows.Forms implementation infringes any patents (so far no one has found any patents that it infringes afaik). And unlike TomTom, Mono is not knowingly infringing on any Windows.Forms patents.
The ECMA 334 and 335 portions of Mono are as safe as any piece of software can get from patent attacks. Mono is probably the single safest piece of software on Linux (ok, that might be pushing it… a lot of the GNU unit tool chain (grep, ls, etc) is probably safer, but only because any patents that those tools infringed have likely expired by now).
Let’s also note that another difference between Mono/Moonlight and TomTom is that Microsoft wasn’t providing test suites to TomTom. If they had been and it was revealed in court, Microsoft would have been laughed out of court. It would have been an open and shut case with Microsoft losing.
Microsoft also do not “use their patents aggressively” (TomTom case is the only time they’ve ever attacked). You’re thinking of Apple who have already used their patents aggressively against F/LOSS on multiple occasions already. IIRC, there has been the spring-loaded folders of Nautilus, FreeType, and something else I can’t remember (was it something to do with itunes?).
[Reply]
Anders Reply:
July 19th, 2009 at 9:49 pm
@alphaomega,
Have you ever read anything about the MS – TomTom case?
It was not about FAT, it was about VFAT, that is short and long file names on the same time.
And no, it was NOT the first time MS has been using patents aggressivly. And yes, Apple have used patents aggressivly too, but that doesn’t make MS right…
So please use your brain at least once in a while (and Google and whatever MS search engine is named) and do some basic research next time, will you?
(How about that offensive conter-attack on your abusive post about opponents intelligence. And English is not my first language, so you could drop that).
Wayne Reply:
May 27th, 2009 at 6:24 am
@Pop Catalin,
In my case, the kids live in my basement, and they use Windows (WOW addicts).
Great technology? An incomplete implementation of a programming language designed by a failed company (as I said earlier, read their SEC filings).
Oh, and they never sue anyone? Ask Tom Tom about that. And then read this article from ITWire:
http://discuss.itwire.com/viewtopic.php?f=29&t=13604&p=48737#p48613
[Reply]
Pop Catalin Reply:
May 27th, 2009 at 9:24 am
@Wayne,
Interesting read, but nothing new, the same old beating on the dead horse.
In Tom Tom’s case the issue was not about patents only, it was a about a Microsoft Licensed technology, the FAT file system, I wish someone would give a real prof and some factual evidence related to mono for patents threats, besides wild speculation backed up by old case which is a whole different matter.
And besides: What patents? Really! What patents are you referring to? I fail to see the threat until someone pinpoints the threatening patents.
> An incomplete implementation of a programming language designed by a failed company.
Incomplete? mono is very complete as far as it is stable and a highly usable product, you’re right it’s incomplete in some areas as it doesn’t implement all windows related things, but on the other hand it’s more complete than .Net in some ways, it’s extensible and open, and we already seen the benefits of this, and I’ll give some examples: Mono SIMD, mono runs on far more platforms and architectures than MS .Net, mono already has compiler services for C# something that MS .Net will only have at the next version.
If you think mono is incomplete, then by all means “send a patch” they will gladly take it ;), you too can help make it more complete. Incomplete is not an issue for a open source technology that sees lot’s of love, because that will go away if ever necessary.
Calling Microsoft a failed company really shows your class, Microsoft was a company that was most likely writing programs on punched tape long before your were born and it’s the biggest “software company” in the world, with that kind of ignorant trolling attitude you can never hope to beat Microsoft in any way.
[Reply]
Wayne Reply:
May 29th, 2009 at 3:04 am
@Pop Catalin,
If you bother to read the actual court filing you will find that it is partly about Patents 5,579,517 and 5,758,352, which cover using long file names in the FAT file system. The issue was patents. You can it here, the patent numbers are on page 3.
As to Mono being incomplete, I’m glad to see you agree with me.
And finally, as to Microsoft. Yes, Microsoft did use punched tape for their earliest software. I learnt Fortran on a mainframe using punched tape several years before that in High School. I’m the same age as Bill Gates (though I’m not as rich). Of course my company isn’t a convicted monopolist either. And yes, Microsoft is a failed company. I would suggest that you go and read their Securities and Exchange Commission filings, and you will see what I mean. The company is in deep trouble, and needs a massive overhaul to survive.
However since the largest shareholder is a close friend of Steve Ballmer, the Chief Executive Officer, removing the CEO is impossible. This means that the company is unlikely to be able to take the actions that need to be taken to ensure it’s survival.
[…] Joseph Shields recommends replacing Rhythmbox with Banshee […]
[…] Joseph Shields recommends replacing Rhythmbox with Banshee […]
[…] powerful. It will be interesting to see how many anti-mono people there are at UDS when we discuss replacing Rhythmbox with Banshee as the default music player in Karmic. Posted by lamalex Filed in C#, Ubuntu, free software, […]
My first experience with Banshee wasn’t that great. But now, after trying version 1.4.3, I say *yes*! Banshee definitely feels more slick and modern, has a more intuitive interface by my impression, and is actively developed. What more to ask?
[Reply]
A few of us tried to push for this at the last UDS, but hit a roadblock when it was discovered that Banshee was missing adequate accessibility support. This appears to still be the case, and I fear that we will run into the same problem if it is proposed again.
It’s unfortunate, as Banshee is seemingly miles ahead of Rhythmbox except for this one area.
[Reply]
directhex Reply:
May 11th, 2009 at 7:14 pm
I’m not well-versed enough in accessibility issues to make any firm comments – though I wonder if this ties in at all to the recently formed Mono Accessibility team – http://mono-project.com/Accessibility
I’d hope that this time around, with a sufficient list of exact issues, that upstream could make things happen (last UDS, Banshee had just undergone a total rewrite, and this meant many issues were on the back burner)
[Reply]
Whatever trolls may say about mono, I am totally in support of banshee as the default music player for Karmic – on all of the many Ubuntu and fedora computers in my house Banshee is used as it is just so much easier to use, it feels much more modern whereas rhythmbox has not visibly changed since I first started using Linux. Also banshee supports on the fly conversion for syncing to ipods thus not stopping people from having their music in ogg just because they have a propitiatory device. So basically banshee provides a better user experience, is easier to use and actually does more to enable the everyday use of free formats but it still needs some improvements in accessibility leading upto karmic as ubuntu must perserve in the ‘no-one left behind’ mentality.
I think it is stupid that many fight against mono just because it uses an open source technology associated with microsoft. The difference between this and something like samba is that microsoft is actually supporting it rather than donning its evil hat, something which FUD watchers cannot stand. The fundermental reasons why Linux people (me as much as anyone) do not like microsoft are 1: its buisness practices – mono is open source and thus not beholden to microsoft (as for patents, microsoft cannot tell us what we can and cannot do), 2: It is not open source but as mono is completely this does not apply, 3: It is competition for Linux on the desktop but as Mono powers applications which vastly improve the Linux desktop experience and not being linux does not automatically make something evil and finally 4: It makes technically inferior technologies but mono/.net is actually nice from a programmers (i.e. someone who is not just judging it on what they require to be true in order to prove their point) standpoint whilst looking much more like it belongs than java software. If it attracts software ports for linux (something we all want) or new innovative native linux software all the better. Just remember that it was the SFF which released gnudotnet even before mono was invented.
[Reply]
As a casual user I can only say this:
Rythembox works but looks old.
Banshee works and looks nicer (but not a lot). So I use Banshee.
[Reply]
Um, I thought it was awful. I generally use VLC or Songbird.
So you think Ubuntu should take legal risks when the licensing situation is unclear? As to Microsoft supporting Mono, how many lines of code have they contributed?
Actually they can. That’s why patents exist.
How does it improve applications? Tomboy Notes really wasn’t very good. F-Spot wasn’t really good. Rhythembox isn’t really good. Where’s the improvement? I don’t see it. What I do see, is developers who either didn’t do a very good job, or were working with a sub-standard set of development tools.
Yes, it’s a technically inferior technology. As to it attracting software ports to Linux, name them. As to the FSF, check Stallman’s current stand – he thinks Mono is dangerous.
A last point. Use the word “innovative” is a warning that the person in question, doesn’t have a clue. Sorry if this sounds a bit nasty, but it’s true. For example Steve Ballmer uses the word a lot, and Microsoft is terrible at developing original ideas. Steve Jobs never uses it, and Apple comes out with really neat and original technology.
[Reply]
My god.
Quick question: If storage size is so important, why not just drop Mono? It would save a lot more than these 6 MB…
“bloated C-based Rhythmbox” I was uncertain that Mono zealots existed, now I am convinced they do.
[Reply]
directhex Reply:
May 27th, 2009 at 2:46 pm
Clearly, you missed the joke. I don’t think Rhythmbox is “bloated”, not at all – but it’s not smaller, and that’s the point.
As for dropping Mono saving space? Sure. But dropping OpenOffice.org would save several times more space. Nobody serious has, to the best of my knowledge, EVER suggested it. Nobody here at UDS has proposed doing it.
[Reply]
[…] near as I can tell, the whole thing really got going from an apebox.org “rant” back around April. In this [cough]fact-filled[/cough] post, the assertion is made that 6.1 MiB will be saved on the […]
[…] Jo Shields, “Fitting the kitchen sink onto a CD“ […]
[…] has to work with far better than I, I just think it is funny that 10MiB here is no big deal, where 6MiB was the entire basis for Jo Shields to start off his “out with Rhythmbox, in with Banshee” drive. And those […]
[…] upside: if Banshee becomes a website, maybe its unconditional lovers will give up their campaign to stick it in everywhere they […]
It is time to make an Haskell media player.
[Reply]
directhex Reply:
July 17th, 2009 at 9:50 pm
@Bodylicious, Shilling for GHC? A REAL player would use COBOL
[Reply]