It depends on the sort of program you're writing. You need the right tool for the job, etc. yadda yadda as we all know.
Scripting languages are convenient for small-ish programs. But going above (for me) about 10,000 lines of code without a static typechecker is very painful. Especially if it's something that's going to need to be maintained for a while.
A good type system can give pretty tight guarantees about your code.
The most broken site I've found is the Odeon cimema page. They are using dHTML to make their nav elements float about in some funky, stupid way and it's useless in any mozilla browser.
(I'm not knocking moz, I love it, just that there are some sites that don't work)
One of the things that annoys me about windows is that your machine becomes part of a very open and highly competitive marketplace. Every application you install wants to take over as much of your space as it can, and does its best to elbow out any competing applications.
For example, my Mum has an XP machine. She has a flatbed Epson scanner, but her Lexmark printer can scan too. Plus I got her a Canon digital camera. If you install the bundled software that comes with all these products (and you have to install at least part of all of them) your machine is a total pickle. Sometimes images pop up in one application, sometimes in another. They fight over who is going to control the printer. They all have a simple image editor, these editors are all completely different, and worst of all, they all have elaborate skins to emphasise their branding. The Canon one was the worst: my Mum is 70 and has trouble reading buttons where the button text is a fixed size rather small bitmap in an unreadable "futuristic" font and is (wait for it) dark grey on mid grey. In fact even working out which bits of the screen are buttons and which are decoration can be pretty challenging.
By contrast Macs are a delight to use because (almost) the only software available is made by Apple and actually (gasp) cooperates. And Linux, erm, well it's not a delight to use, but if you enjoy tinkering it can be OK, and at least most projects try to rub along discreetly.
I remember my supervisor's line was that having a PhD would make some jobs harder to get, but that they would mostly be jobs that would have bored you to tears anyway. Plus it opens up a bunch of (potentially) very interesting research posts.
I temped for 6 months after my viva (in a glue factory, heh) before finding a research place. It's a great job and I wouldn't have got it without the PhD.
I agree, a good digital now beats 35mm quite easily. Film advocates produce amazing lpi figures for (usually) Velvia then argue that they're somehow getting the equivalent of 20 megapixels or whatever. Film lpi figres are usually for a 20% contrast ratio and are just not at all comparable to digital (where the contrast ratio is obviously 100%).
As I understand it, the figures come from comparing the ratios of number-of-species-per-cubic-metre in fossil beds above and below the extinction line. You don't need to know the absolute number of species in order to be able to estimate the ratio.
I still use reiserfs, I wasn't complaining about it (I guess I wasn't clear). I was just saying that a journalled FS does not automatically protect your data if you randomly pull the plug. You're right that it was the nv driver that caused the crash.
I've lost stuff with reiser too. About a year ago I was fiddling with an nvidia driver and locked my machine up. When I rebooted the tree that had had a compile going on had vanished forever.
My understanding is that journalled means the FS can't get into an inconsistant state and so does not need fsck-ing. It does not mean your data is safe from having the power pulled halfway through a write. If you want a super-safe home area you want some sort of logging FS and these are all far slower than journalled (I think).
If you're interested in Turing, you might like the Turing Archive. This site has scans of a lot of his personal papers and research notes. You can read all his unpublished stuff too:)
No one has mentioned UPS yet. I'm not sure you could really call it revolutionary, but it does have a few interesting features:
Not based on gdb, amazingly. Does C/C++/FORTRAN on linux, freebsd and solaris.
As your program runs you see an animated view of the machine at roughly source-code level (ie. text style, not ddd-like graphical).
It includes a C interpreter... you can write scraps of C and attach them to parts of your program as it runs. You can use the C interpreter to write watches and conditional breakpoints etc.
It's based on the Athena widget set so it now looks incredibly ugly. OTOH, it also makes it very quick.
Like other people here I debug mostly with printfs() logged to a file for easy searching, supplemented with valgrind, memprof and occasionally UPS. They are all tools and you need to try to pick the right one for the sort of bug you think you're facing.
Most large format inkjet printers (eg. HP 5500) max out at about 200 pixels per printed inch (pppi). So for your 11 x 17" print, you'll need 2200 by 3400 pixels, or about 7.5 MP. The next generation are supposed to be able to do more detail than this. Anyway, pppi is a very helpful way to think about the image size you need.
(Don't look at the manufacturer's claims of 4800 dpi or whatever, that's just marketing. What matters is drop size and ink colour; how accurately you position them is much less important.)
I read your NASA link and it does not say "all of the above are bunk". It says satellite measurements of upper atmosphere temperature do not appear to agree well with current (1998) climate models. The page approvingly quotes the UK met office global warming figure of 0.15C/decade.
I don't think anyone seriously disputes or has disputed that the earth is getting hotter and that we are likely to see changes to the climate as a result. People (especially the oil lobby) do dispute the causes of warming, the severity of the effect, and what (if anything) could be done to stop it. I think that's why you're seeing a range of senarios in your other links.
There's another factor: the ice is trapped at the poles, whereas liquid water would be free to move.
The oceans bulge around the equator because of the earth's spin, so more liquid water == more equatorial bulge, and therefore rising sea levels (in some part of the world).
Actually, the PERQ was Unix. It ran something they called P/NX (no, really, it was pronounced pee-nix) and was widely regarded as the worst Unix ever made.
The most laughable misfeature I remember was that you couldn't fork() a process larger than 128k. And this is on a graphics workstation, remember. Imagine the hacks people came up with to work around that one.
I remember doing an experiment in Physics at school to show this. Here's what we did:
get an LED, a variable power supply and a sensitive ammeter
sit with this stuff in a completely darkened room for 10 minutes so your eyes adapt
sit a known distance (eg. 1 meter) from the LED and slowly turn down the power until you can only just see it
wait a bit, try looking with your peripheral vision, wait a bit more, you'll find you can turn it down further
there's a point where if you concentrate you can still just guess where the LED is, stop there
Now: assuming the LED is 100% efficient (close enough) and that your pupils are (eg.) 1 square cm at (eg) 1m from the source, you can calculate how many photons / second were entering your eye.
Of course we were young (hmm, 17?) and this is only an order or magnitude experiment, but most people could go down to somewhere around 1 - 10 photons / second.
Don't forget SunView. I actually wrote a few programs for that, about 15 years ago.
It had this wonderful feature that each window a process had on the screen had a corresponding pseudo tty. And the whole thing was done in kernel space. And you were stuck with their widgets. It was so awful that it seemed like a giant leap forward when Sun added an integrated X server. With 20 pixel black borders around the windows that X was managing.
Of course you could login with NeWS instead. NeWS had this brilliant thing where if you had an 80x25 terminal window and you sized it larger, the terminal window stayed 80x25 but it enlarged the font to fill the new window. Actually, being a CS PhD with no interest in the practical side of a window system, I liked NeWS. I wrote a breakout game in Postscript that ran entirely inside the server. I like to think that, with luck, Y windows could repeat some of this brilliance.
On the plus side, SunView could have rounded corners on buttons, which X didn't manage for another 10 years.
Yes, Linux has always had (variations) on the elevator algorithmn.
This is different: the scheduler isn't trying to minimise head movement for a list of pending read requests (which is what elevator does), it's gathering statistics about the IO behaviour of each process and trying to guess in advance without being asked what each process will ask for next.
If it guesses right, the data will already be in cache when the process does a read() and the request will succeed instantly.
A big part of the slowness of gtk2 is font rendering. Motif uses (or used?) XDrawString(), so text was done entirely by the server. On the downside, the quality of the text rendering was very poor.
gtk2 draws all text with pango. Pango is a high-quality unicode text renderer with an Xft2 backend. If you have an old X server, this can be pretty slow. If you have a recent XRender extension, it's almost as fast as the old XDrawString().
Owen Taylor did add an optimisation to render text more quickly for text which gtk knows is being drawn over a plain background, this helps old X servers a lot, provided you're not using a pixmap-based theme.
I think you're maybe confused: X over networks works at the "draw a line from X to Y" level. If part of a window is damaged, the client is sent the coordinates of the damaged area and asked to redraw it.
I was trying to explain it from an implementation point of view: monads are implemented with continuations, and many C programmers will have come across them.
Slashdot Mirror
You've linked to a shot of the gnome 2.4 file requestor. This is what the gnome 2.6 one looks like.
I still think I'm right through :-) if you're picking a language for a largish project, a good static typechecker should be on your shopping list.
It depends on the sort of program you're writing. You need the right tool for the job, etc. yadda yadda as we all know.
Scripting languages are convenient for small-ish programs. But going above (for me) about 10,000 lines of code without a static typechecker is very painful. Especially if it's something that's going to need to be maintained for a while.
A good type system can give pretty tight guarantees about your code.
(I'm not knocking moz, I love it, just that there are some sites that don't work)
I think he means MDI (which is very annoying if you're not used to it).
One of the things that annoys me about windows is that your machine becomes part of a very open and highly competitive marketplace. Every application you install wants to take over as much of your space as it can, and does its best to elbow out any competing applications.
For example, my Mum has an XP machine. She has a flatbed Epson scanner, but her Lexmark printer can scan too. Plus I got her a Canon digital camera. If you install the bundled software that comes with all these products (and you have to install at least part of all of them) your machine is a total pickle. Sometimes images pop up in one application, sometimes in another. They fight over who is going to control the printer. They all have a simple image editor, these editors are all completely different, and worst of all, they all have elaborate skins to emphasise their branding. The Canon one was the worst: my Mum is 70 and has trouble reading buttons where the button text is a fixed size rather small bitmap in an unreadable "futuristic" font and is (wait for it) dark grey on mid grey. In fact even working out which bits of the screen are buttons and which are decoration can be pretty challenging.
By contrast Macs are a delight to use because (almost) the only software available is made by Apple and actually (gasp) cooperates. And Linux, erm, well it's not a delight to use, but if you enjoy tinkering it can be OK, and at least most projects try to rub along discreetly.
I temped for 6 months after my viva (in a glue factory, heh) before finding a research place. It's a great job and I wouldn't have got it without the PhD.
This is a bit old now, but here's a piece comparing the 1Ds to drum scanned medium format film. http://www.luminous-landscape.com/reviews/shootout .shtml. If an 11 MP digital beats medium format, a 6 MP digital is going to look pretty good next to 35mm.
gtk+-1.2 apps look ugly on windows
... did you look at the screenshots linked by the parent?
gtk+-2.x apps with the gtkwin theme (xp and 2k only, I think) look fine
As I understand it, the figures come from comparing the ratios of number-of-species-per-cubic-metre in fossil beds above and below the extinction line. You don't need to know the absolute number of species in order to be able to estimate the ratio.
I still use reiserfs, I wasn't complaining about it (I guess I wasn't clear). I was just saying that a journalled FS does not automatically protect your data if you randomly pull the plug. You're right that it was the nv driver that caused the crash.
My understanding is that journalled means the FS can't get into an inconsistant state and so does not need fsck-ing. It does not mean your data is safe from having the power pulled halfway through a write. If you want a super-safe home area you want some sort of logging FS and these are all far slower than journalled (I think).
If you're interested in Turing, you might like the Turing Archive. This site has scans of a lot of his personal papers and research notes. You can read all his unpublished stuff too :)
No one has mentioned UPS yet. I'm not sure you could really call it revolutionary, but it does have a few interesting features:
Like other people here I debug mostly with printfs() logged to a file for easy searching, supplemented with valgrind, memprof and occasionally UPS. They are all tools and you need to try to pick the right one for the sort of bug you think you're facing.
(Don't look at the manufacturer's claims of 4800 dpi or whatever, that's just marketing. What matters is drop size and ink colour; how accurately you position them is much less important.)
I don't think anyone seriously disputes or has disputed that the earth is getting hotter and that we are likely to see changes to the climate as a result. People (especially the oil lobby) do dispute the causes of warming, the severity of the effect, and what (if anything) could be done to stop it. I think that's why you're seeing a range of senarios in your other links.
The oceans bulge around the equator because of the earth's spin, so more liquid water == more equatorial bulge, and therefore rising sea levels (in some part of the world).
The most laughable misfeature I remember was that you couldn't fork() a process larger than 128k. And this is on a graphics workstation, remember. Imagine the hacks people came up with to work around that one.
Now: assuming the LED is 100% efficient (close enough) and that your pupils are (eg.) 1 square cm at (eg) 1m from the source, you can calculate how many photons / second were entering your eye.
Of course we were young (hmm, 17?) and this is only an order or magnitude experiment, but most people could go down to somewhere around 1 - 10 photons / second.
Heh, Tolkein was South African, not British.
It had this wonderful feature that each window a process had on the screen had a corresponding pseudo tty. And the whole thing was done in kernel space. And you were stuck with their widgets. It was so awful that it seemed like a giant leap forward when Sun added an integrated X server. With 20 pixel black borders around the windows that X was managing.
Of course you could login with NeWS instead. NeWS had this brilliant thing where if you had an 80x25 terminal window and you sized it larger, the terminal window stayed 80x25 but it enlarged the font to fill the new window. Actually, being a CS PhD with no interest in the practical side of a window system, I liked NeWS. I wrote a breakout game in Postscript that ran entirely inside the server. I like to think that, with luck, Y windows could repeat some of this brilliance.
On the plus side, SunView could have rounded corners on buttons, which X didn't manage for another 10 years.
This is different: the scheduler isn't trying to minimise head movement for a list of pending read requests (which is what elevator does), it's gathering statistics about the IO behaviour of each process and trying to guess in advance without being asked what each process will ask for next.
If it guesses right, the data will already be in cache when the process does a read() and the request will succeed instantly.
A big part of the slowness of gtk2 is font rendering. Motif uses (or used?) XDrawString(), so text was done entirely by the server. On the downside, the quality of the text rendering was very poor.
gtk2 draws all text with pango. Pango is a high-quality unicode text renderer with an Xft2 backend. If you have an old X server, this can be pretty slow. If you have a recent XRender extension, it's almost as fast as the old XDrawString().
Owen Taylor did add an optimisation to render text more quickly for text which gtk knows is being drawn over a plain background, this helps old X servers a lot, provided you're not using a pixmap-based theme.
I think you're maybe confused: X over networks works at the "draw a line from X to Y" level. If part of a window is damaged, the client is sent the coordinates of the damaged area and asked to redraw it.
I was trying to explain it from an implementation point of view: monads are implemented with continuations, and many C programmers will have come across them.