Hate on a dead person, for real? You must be great fun at parties. I wish the dead would be remembered for the good they brought, but almost a year later she's still much misunderstood.
3,510 karma · joined August 4, 2012
Hate on a dead person, for real? You must be great fun at parties. I wish the dead would be remembered for the good they brought, but almost a year later she's still much misunderstood.
"The problem with socialism is that eventually
you run out of other people's money"
-- Margaret ThatcherOr build an AeroQuad: http://aeroquad.com/content.php?s=9af9c997f8aed9a3ad958e32bf...
CDs:
https://itunes.apple.com/us/album/absolute-amiga-compilation/id436035771
http://dataairlines.bandcamp.com/
Actual mod, it, s3m etc. files:
http://modarchive.org/
http://www.keygenmusic.net/
Demos:
http://www.pouet.net/
Artists:
http://www.8bitweapon.com/
http://kubbi.bandcamp.com/
https://soundcloud.com/goto80
http://gwem.bandcamp.com/
https://soundcloud.com/sabrepulse
http://047.se/
Commodore64 music:
http://www.hvsc.c64.org/
https://play.google.com/store/apps/details?id=net.bitheap.sidplayer
There's also plenty of material on Spotify and Grooveshark. If you need a player, Audacious / Banshee / Foobar2k / ModPlug Player / mpd / VLC / Winamp / XimpleMOD... Many players will work, try your existing player if you're not using one of the aforementioned players.(I wouldn't be surprised anymore if the NSA has a backdoor in it, in addition to the continuously growing list of known security vulnerabilities.)
Try right-clicking here to see this workingAh, what you wrote earlier makes sense in light of this :)
> In C, you sacrifice safety (undefined behaviour etc.) for speed.[...]
You can write slow code in any language, a program isn't necessarily fast because it's been written in C. It's fast because it's been written with runtime efficiency in mind. Undefined behaviour comes from not making unnecessary assumptions on the underlying platform, which aids portability.
> But has a minimum of three times the memory overhead.[...]C sacrifices safety for speed and memory efficiency
Memory efficiency, yes. I, for one, prefer not to rely on a garbage collector and verify correctness with valgrind. You do have to diligently manage memory, or any language that assumes GC may win in the long run. Speed, however, was never a goal of C. You could argue the same thing with assembly, if you do all of the hard work yourself the result can be faster and more efficient than the same application in C. Neither was meant to be fast or efficient on its own, but may be considered as such when compared to higher level languages.
> There is a JVM for mips isn't there?
It exists, but it's proprietary.
> Or don't you have enough memory?
Not by a long shot, usually.
> JVM languages uses alot more memory than a native program, that doesn't necessarily make JVM-based languages any less portable.
Not on principle, but in practise it does.
> The same .jar file can be executed on Windows, Linux, Mac and more operating systems without a recompile. [...] I'd argue that they are more portable than C.
You simply moved the problem from the program itself to the underlying platform. By that logic, I can prove a PPC binary is portable by running it in qemu on x86. As long as there's a PPC or Java bytecode implementation, the hypothetical programs will work. Fact remains that given Java or C source code, the C code will end up being more portable.
> Last but not least, it's important to use the right tool for the right job. I would never write a VM in a JVM-based language [...] never write a GUI application in C.
I absolutely agree with using the right tool for the job, so never say never. Both examples can be perfectly reasonable ways to get a certain job done, we just don't see them very often.
Also, I disagree C is a tradeoff for speed an efficiency. Runtime speed and efficiency? Development time perhaps? I can easily write parallel code in scala that defeats idiomatic C on both. I use C when I want something portable. I can't use the scala code on a tiny mips device, but I can port the C code if it's reasonably well written. Same goes for any other target, there's nothing so pervasive as C.
It's just been hidden (and there's no need to set up email).
Problem solved.
That makes no sense. We had a perfectly working init called System V init. That's an alternative here, you may be looking at the wrong operating system.
A lot of the complexity comes from how flexible it is.
I think the complexity comes from trying to do too much at once. It's an init, but also cron. It's still an init, but also inetd. But it is still init, yet also acpid. Although it is in fact, still init, it's also atd.
And all of its functionality is available as a DBUS API. The only users are developers writing programs, not anyone banging their keyboards at the commandline prompt. That flies into the face of everything that made GNU/Linux great. Dbus is the death of GNU as we know it. The *sh oneliner that uses pipes and plain works is much better than the far more efficient C (or programming language du jour) program, even if it's only 10 lines of code.
You might think of a tiling window manager as being the greatest invention since sliced bread, but having to configure it in Haskell FFS (I'm looking at you, xmonad) just doesn't jive with me. Nor does any other tiling window manager except WindowMaker (oh, pardon me, that's a tiled window manager). KDE is just as bad because it has too many bells and whistles, it doesn't follow KISS principles. Is that a straw man to you?
Gnome managed to create a nice iteration of gnome-shell with 3.6, but it was riddled with bugs (it still is, albeit to a lesser extent). Then they had to ruin it in 3.8. Categories are for losers, right? Let's remove that. And no one ever needs accessibility, right? Let's git rid of that, too. And what's with all these keyboard layout options? Can't have that, way too useful! Yeah we put some of them back in gnome-tweak-tool but not all because obviously no one ever used them for anything. The final straw for Gnome (for me) was when shell extensions that were never meant to appear in the lock screen, did in fact, appear in the lock screen. The gnome-screensaver they got rid of did one thing really well, but they couldn't find a way to let it display notifications so they axed it.
I'll do my best to make Fedora 20 work because it offers the option of installing MATE, which is Gnome 2.x based. So it packages all of the latest gizmo's (for better or worse) and presents it with a friendly face without an identity crisis (it knows it's a PC, not a tablet). Though I'm on my 3rd install now, at some point the installer stops working resulting in a blinking cursor when I turn it off and on. It works perfectly in a VM, but I want the real deal. (It did pass verification.)
It just baffles me whenever I look at it.