I'm having a similar experience with KDE on P2 Laptop (only 266, I think), with maybe 96MB ram. This system used to crawl with win98 on it, and was horribly unstable to boot. Now it runs reasonably well -- admittedly it takes ~10 minutes to boot up/log in, but after that I don't really notice the slowness.
I'm also a new grad looking for a job (though I have an MS which some employers consider equivalent to a couple of years experience), and my experience is that the listed job requirements are often BS.
I've applied nd gotten interviews for a number of positions 'requiring' 3+ or 5+ years of experience, and experience with a slew of toolkits, libraries, etc that I know nothing about. I haven't been hired yet, but employers are willing to consider me seriously even when I have nowhere near the experience they are asking for.
So if you see a job you like, send off a resume even if they want a little more experience than you've got.
Also, if you can, try to get in touch with recruiters -- they can be very useful in getting you noticed and asked in for an interview.
I'm not sure that vector graphics really solve the widget layout problem. Say I have a 1024x768 desktop, and I have an editor window (a toolbar across the top and a big text area) open which is sized to 640x480.
If I maximize the window, I want the toolbar to stay the same size, but the text area to get bigger... just scaling everything won't work.
Having (briefly) done some research in program verification, I'd have to disagree with you. Proving non-trivial programs correct is nearly always intractable, if not strictly speaking impossible. We simply don't have the computing power to do it for larger programs, and (IMO) we probably never will.
It's actually quite different. Eiffel lets you embed contracts in your code which are (optionally) checked at run-time. Even with contracts, your program can pass all its tests and still have hidden bugs.
Alloy lets you model a system (Alloy code isn't executable), and statically prove properties about the model. Once you verify the model, you prove that it's correct for all possible runs (but you still have to implement it correctly).
The mobile athlon is pin-compatible with a normal athlon, and there are motherboards which support it. I'm running one in my Shuttle SK41, and it's basically inaudible.
DbC is more powerful than asserts -- in addition to pre/post blocks (that always get called no matter which return path your code takes), you can write class invariants that are checked after every method of a class.
Plus, the pre/post conditions and invariants can be automatically extracted to generate documentation.
At least, that's how it works in Eiffel, which basically pioneered DbC. I don't know the details of D's implementation.
Actually, the post was a bit misleading -- D only provides *link* compatibility with C. You can link to C libraries without any trouble, but you can't compile C source code in the D compiler.
Oops, it appears that Zero Install actually _does_ automatically resolve dependencies, in a rather elegant way even. (And without using static linking, I might add).
There are lots of well-known reasons why static linking is a bad idea:
1) Ease of updating. If there's a new release of, say, Qt, I install it an all my dynamically-linked Qt apps get the upgrade. With static linking, I have to upgrade every app separately, which means either waiting for the distributor to release a new build, or compiling it myself.
2) Load time. If all my Qt/KDE programs are statically linked, each one has to read ~10M of library code off the disk when it starts.
3) Disk space. I have about 100 packages on my system that depend on KDE/Qt or Gnome/GTK. If each one has its own copy of the 10M of GUI libraries it needs, that wastes a gig of space. Not intolerable with today's hard drives, but a lot of space nonetheless.
Static linking only solves dependency problems, and at a great cost. Good package management can also solve dependency problems without the problems of static linking.
The Zero-Install concept is a nice way to install applications, but I think it would really shine if coupled with an apt-like system for automatically installing the needed libraries. Static linking is not the answer.
Just the other day I ran knoppix on a PII 266 laptop wi/ 64 megs. I used a swapfile on the windows partition and booted into the XFCE desktop in KDE. It took a while to start up, but other than that ran fine.
Not to bash ruby (it's actually my favorite language), but I wouldn't describe it as "pretty fast". In all the benchmarks I've seen it is slower even than other interpreted scripting languages like Perl/Python.
AFAIK it's still the only online music service without DRM. Not to mention Linux support (although it does taking a bit of work to get that set up).
That said, I tend to forget about it for months at a time, and then go and download 5 or 6 albums in a day. I was already at the point where the service was just barely worth it, and the new pricing structure just tipped the scales.
Mandating open source software does not grant exclusive control to a single party. There are many different companies selling open source solutions, and (as others have pointed out), nothing is stopping MS from selling open source products to the state of Massachussetts.
"Working" is a somewhat strong term for emusic's linux client. Most people can get it to mostly work if they read through the forums to learn the workarounds for all of its bugs.
I am a long-term emusic subcriber and until recently very happy... but anyone using linux might want to think twice, given the hoops you have to jump through to download anything now.
Have you looked at Lyx? I've used both Frame and Lyx to write research papers, and found Lyx to be a lot less painful.
OTOH, I don't know what you use frame for, and it may have some all-important feature that lyx lacks. Of course, lyx is latex-based and lets you embed latex in it, so if you can deal with writing latex by hand there is basically nothing you can't get lyx to do.
Well static typing makes the parse tree richer in the same way that requiring you to list your religion on a driver's license application makes the DMV's database richer. I'm not convinced of the benefit.
Access modifiers are either a declaration that you are more intelligent than your users, or a way to hide your bad code from other people.
Static typing expresses the programmer's intent, which can be quite useful for program understanding. The same is true of access modifiers. And, access modifiers allow you to safely separate the implementation of your class from its interface.
The general argument against walmart is this:
They pay their employees shit (as well as busting unions and various other unscrupulous practices), so all of the money that Walmart makes is concentrated in the hands of the owners of the company, who are already filthy rich, as opposed to back into the local community. The result is uneven distribution of wealth, and a weaker local economy (b/c all the money is going elsewhere).
Small businesses, on the other hand, in general pay their employees better, and the owners themselves are local, so basically all of their profit is going back into the local economy. Additionally, since the employees are paid better and the owners are probably not obscenely rich, wealth is distributed more evenly on the whole.
The problem is that, from an individual perspective, it may make sense to shop at wallmart . (Some ppl prefer small stores where they can actually find what they're looking for, but most don't seem to care). But, shopping at walmart damages the community, which in turn hurts the individual -- but in an indirect way, so that the individual doesn't connect the resulting problems back to walmart, and therefore has no reason to stop shopping there.
The problem with java is that it's very heavy-weight. The APIs are complex, and you have to write a lot of boilerplate code before you can do anything (i.e. public static void main...).
Something like LOGO or basic is ideal -- you can type 'print "Hello world!"' and get instant results.
Implementing all of them in the kernel would bloat the kernel a lot. What KDE/Gnome should have done (and what LUFS, mentioned in another thread, seems to do), is have a small kernel module that calls a userspace daemon. All of the protocol code stays in userspace, but the kernel module makes the filesystem accessible to all programs. The overhead from the context switch doesn't matter when you're dealing with remote filesystems.
It's a pretty slick idea, actually... maybe it will be integrated into the major DEs someday.
I think the point of the original post was that, eventually you will need IE 7 (or Mozilla 2.x) to view most web pages. And to get IE 7, you will need windows 2005, which means you need a new computer.
Faced with the choice of buying a new computer or installing Mozilla, many people will choose the latter -- especially if they have a geeky friend to suggest it to them and maybe help with the install.
a) For city-to-city travel, there are buses, trains, and air travel. If you want to go to the country, rent a car. For occassional trips, it is almost certainly cheaper than owning your own car.
b) I can carry a week's worth of groceries (for myself) on my bike with two bags that hang off the back rack. And, if the grocery store is conveniently located (which presumably you can manage if you are designing an entire city to be car-free), it's no big deal to go shopping a few times a week.
As for your family, they can ride the bus too, can't they?
Slashdot Mirror
Then clearly you should be fined for the lost penis enlargement sales that would have resulted had you been male and insecure about your penis size.
I'm having a similar experience with KDE on P2 Laptop (only 266, I think), with maybe 96MB ram. This system used to crawl with win98 on it, and was horribly unstable to boot.
Now it runs reasonably well -- admittedly it takes ~10 minutes to boot up/log in, but after that I don't really notice the slowness.
I'm also a new grad looking for a job (though I have an MS which some employers consider equivalent to a couple of years experience), and my experience is that the listed job requirements are often BS.
I've applied nd gotten interviews for a number of positions 'requiring' 3+ or 5+ years of experience, and experience with a slew of toolkits, libraries, etc that I know nothing about. I haven't been hired yet, but employers are willing to consider me seriously even when I have nowhere near the experience they are asking for.
So if you see a job you like, send off a resume even if they want a little more experience than you've got.
Also, if you can, try to get in touch with recruiters -- they can be very useful in getting you noticed and asked in for an interview.
I'm not sure that vector graphics really solve the widget layout problem. Say I have a 1024x768 desktop, and I have an editor window (a toolbar across the top and a big text area) open which is sized to 640x480.
If I maximize the window, I want the toolbar to stay the same size, but the text area to get bigger... just scaling everything won't work.
If you don't like the middle mouse button, how about buying a two-button mouse?
Having (briefly) done some research in program verification, I'd have to disagree with you.
Proving non-trivial programs correct is nearly always intractable, if not strictly speaking impossible. We simply don't have the computing power to do it for larger programs, and (IMO) we probably never will.
It's actually quite different. Eiffel lets you embed contracts in your code which are (optionally) checked at run-time. Even with contracts, your program can pass all its tests and still have hidden bugs.
Alloy lets you model a system (Alloy code isn't executable), and statically prove properties about the model. Once you verify the model, you prove that it's correct for all possible runs (but you still have to implement it correctly).
The mobile athlon is pin-compatible with a normal athlon, and there are motherboards which support it.
I'm running one in my Shuttle SK41, and it's basically inaudible.
DbC is more powerful than asserts -- in addition to pre/post blocks (that always get called no matter which return path your code takes), you can write class invariants that are checked after every method of a class.
Plus, the pre/post conditions and invariants can be automatically extracted to generate documentation.
At least, that's how it works in Eiffel, which basically pioneered DbC. I don't know the details of D's implementation.
Actually, the post was a bit misleading -- D only provides *link* compatibility with C. You can link to C libraries without any trouble, but you can't compile C source code in the D compiler.
Oops, it appears that Zero Install actually _does_ automatically resolve dependencies, in a rather elegant way even. (And without using static linking, I might add).
There are lots of well-known reasons why static linking is a bad idea:
1) Ease of updating. If there's a new release of, say, Qt, I install it an all my dynamically-linked Qt apps get the upgrade. With static linking, I have to upgrade every app separately, which means either waiting for the distributor to release a new build, or compiling it myself.
2) Load time. If all my Qt/KDE programs are statically linked, each one has to read ~10M of library code off the disk when it starts.
3) Disk space. I have about 100 packages on my system that depend on KDE/Qt or Gnome/GTK. If each one has its own copy of the 10M of GUI libraries it needs, that wastes a gig of space. Not intolerable with today's hard drives, but a lot of space nonetheless.
Static linking only solves dependency problems, and at a great cost. Good package management can also solve dependency problems without the problems of static linking.
The Zero-Install concept is a nice way to install applications, but I think it would really shine if coupled with an apt-like system for automatically installing the needed libraries. Static linking is not the answer.
Just the other day I ran knoppix on a PII 266 laptop wi/ 64 megs. I used a swapfile on the windows partition and booted into the XFCE desktop in KDE. It took a while to start up, but other than that ran fine.
1) Ion window manager.
2) Beowulf clusters.
3) KDE's kio architecture (or gnome-vfs. Not sure which came first).
Not to bash ruby (it's actually my favorite language), but I wouldn't describe it as "pretty fast".
In all the benchmarks I've seen it is slower even than other interpreted scripting languages like Perl/Python.
AFAIK it's still the only online music service without DRM. Not to mention Linux support (although it does taking a bit of work to get that set up).
That said, I tend to forget about it for months at a time, and then go and download 5 or 6 albums in a day. I was already at the point where the service was just barely worth it, and the new pricing structure just tipped the scales.
Mandating open source software does not grant exclusive control to a single party. There are many different companies selling open source solutions, and (as others have pointed out), nothing is stopping MS from selling open source products to the state of Massachussetts.
"Working" is a somewhat strong term for emusic's linux client. Most people can get it to mostly work if they read through the forums to learn the workarounds for all of its bugs.
I am a long-term emusic subcriber and until recently very happy... but anyone using linux might want to think twice, given the hoops you have to jump through to download anything now.
Have you looked at Lyx?
I've used both Frame and Lyx to write research papers, and found Lyx to be a lot less painful.
OTOH, I don't know what you use frame for, and it may have some all-important feature that lyx lacks. Of course, lyx is latex-based and lets you embed latex in it, so if you can deal with writing latex by hand there is basically nothing you can't get lyx to do.
The general argument against walmart is this:
They pay their employees shit (as well as busting unions and various other unscrupulous practices), so all of the money that Walmart makes is concentrated in the hands of the owners of the company, who are already filthy rich, as opposed to back into the local community. The result is uneven distribution of wealth, and a weaker local economy (b/c all the money is going elsewhere).
Small businesses, on the other hand, in general pay their employees better, and the owners themselves are local, so basically all of their profit is going back into the local economy. Additionally, since the employees are paid better and the owners are probably not obscenely rich, wealth is distributed more evenly on the whole.
The problem is that, from an individual perspective, it may make sense to shop at wallmart . (Some ppl prefer small stores where they can actually find what they're looking for, but most don't seem to care). But, shopping at walmart damages the community, which in turn hurts the individual -- but in an indirect way, so that the individual doesn't connect the resulting problems back to walmart, and therefore has no reason to stop shopping there.
The problem with java is that it's very heavy-weight. The APIs are complex, and you have to write a lot of boilerplate code before you can do anything (i.e. public static void main...).
Something like LOGO or basic is ideal -- you can type 'print "Hello world!"' and get instant results.
Implementing all of them in the kernel would bloat the kernel a lot. What KDE/Gnome should have done (and what LUFS, mentioned in another thread, seems to do), is have a small kernel module that calls a userspace daemon. All of the protocol code stays in userspace, but the kernel module makes the filesystem accessible to all programs. The overhead from the context switch doesn't matter when you're dealing with remote filesystems.
It's a pretty slick idea, actually... maybe it will be integrated into the major DEs someday.
I think the point of the original post was that, eventually you will need IE 7 (or Mozilla 2.x) to view most web pages. And to get IE 7, you will need windows 2005, which means you need a new computer.
Faced with the choice of buying a new computer or installing Mozilla, many people will choose the latter -- especially if they have a geeky friend to suggest it to them and maybe help with the install.
a) For city-to-city travel, there are buses, trains, and air travel. If you want to go to the country, rent a car. For occassional trips, it is almost certainly cheaper than owning your own car.
b) I can carry a week's worth of groceries (for myself) on my bike with two bags that hang off the back rack. And, if the grocery store is conveniently located (which presumably you can manage if you are designing an entire city to be car-free), it's no big deal to go shopping a few times a week.
As for your family, they can ride the bus too, can't they?