Otherwise how would caring about single window mode require one to be a Windows drone?
"Require" is a strong word, but my long-term impression of the Gimp is that it is fine if you can give it its own virtual desktop, and moderately unusable if you can't.
Practically speaking, what that translates to is that it works fine in Linux and is moderately unusable in Windows; not many people have a virtual desktop application for Windows. (They do exist, and are definitely usable, but they aren't as smooth as WMs on Linux.)
Things are better than they used to be though. I'm not sure about this because I haven't used it in a while, but I think the Gimp will now raise all its tool windows when you raise one. Before that it was almost completely unusable if you couldn't devote a virtual desktop.
I disagree. Is there really some super-pressing feature that you can't wait a couple more days for.8? And what if you don't call crypt(), but some library you're using does? Are you that familiar with all of your code base? And what about in the future? What if in 6 months you decide to use crypt(), are you going to remember about this bug? (Hopefully you'd notice that your logins are always successful.)
I'm not necessarily saying it should be totally unavailable, but I don't think it should be particularly easy to get to.
(Or maybe I would consider replacing the download with one that unzips to a couple additional higher level directories: this_release_has_a_buggy_crypt/read_security.txt_first/.)
The internal crypt() function of PHP is only there whenever the system function doesn't exist.
This is not correct.
Ondrej's post you link to is specifically referring to the patched version of PHP that you get from the Debian repository. One of the patches Ondrej applies makes PHP use the system crypt(). Without that patch -- with the stock PHP code -- PHP uses its own crypt(). Now, other distributions might apply Ondrej's patch, but I certainly wouldn't count on it, and you definitely will have a broken crypt() if you get the stock PHP.
Worked in Software Dev & Support for 12 years. Never once seen a Regression test find something that is broken
I think you're full of BS. In fact, this particular bug was found by a regression test; just no one noticed because they have so many failing tests because their process is non-existent.
Oh, and not only is the project's QA apparently nonexistent (not that they're the only big project that doesn't have useful tests), they also don't have any sense when it comes to their website. OK, they posted a message that 5.3.7 has a severe security bug on their front page; that's a good start.
But they then should have pulled the release, and made it deliberately difficult to get to. They didn't. If you Google "PHP", the second link is to their download page, and you can grab 5.3.7 from there without ever seeing that warning.
I'm pretty sure that the project is run by a bunch of 12 year olds.
I think that the post you replied to was a bit extreme, but it's not the bug in the library function that caused him to say that: it's the fact that the PHP project lacks the testing infrastructure that any reasonable project of that size would have.
Anyone can commit a bug; that's easy and excusable. What makes it look like PHP is developed by a bunch of 12 year olds is the fact that they have a test suite with a test that exhibited the bug, and yet no one ran it before they made a release, because they've got too many failing tests so it just got swamped in with that noise.
I'm working on some dinky pieces of research software, and while we probably don't have as extensive a test suite as PHP does, we have a way better testing regimen. A project like PHP should have a CI server that runs their tests at least nightly, and a release shouldn't be made while there are failing tests. That's what expected failures are for. (They even know about expected failures, but still have over 200 failing tests for some reason.) Even we've got that.
Impossible? No, look at the FreeRunner. (Or to a lesser extent, the N900.)
But likely? I think no. I honestly think that Android would not be in nearly the place that it is in right now the phone manufacturers were not able to lock them down. The phone manufacturers are probably relatively indifferent on their own, but the carriers love the fact that they are locked down, and that's where a lot of the real power lies. If Verizon and AT&T say "no, your platform is too open, we're not going to promote or subsidize your phones (it makes it harder to prevent tethering and upsell stuff)", how many of those phones would be sold?
I'm not saying it necessarily would play out that way, but at least if you look at market share, I think it's entirely possible that in a world with actual open phones, the benefactors would be the iPhone and WinMo.
The engineer in charge of the offices I once worked at kept the thermostat at 65 degrees "to save energy". Didn't matter that it was the middle of the summer with the AC going full blast and all the secretaries wearing sweaters.
It is hypothetically possible that he's correct. I recently learned that several buildings on the University I go to have what's called a "reheater" system. All air entering the building is cooled to 55 degrees in order to drop the humidity -- then is reheated back to whatever the thermostat setting is. Lowering the temperature on the thermostat doesn't cost any extra A/C, and saves on heating.
Probably not what was going on in your case, but theoretically possible, and an interesting tidbit in any case.
It can be used on multiple monitors and supports at least 9 virtual desktops.
I have... 27 virtual desktops available, and it has no problem with that. (These are shortcut to Win + 0-9, F1-F12, A, I, and T, G, and B (for those last three, think about a split keyboard).) Though usually only half or so are actually being used.
Basically for me, one desktop gets one or two windows. (Often this is Emacs and a terminal.) Windows that are related by task beyond that get nearby desktops: desktop F4 may be an Emacs window with a Latex document alongside a terminal in that directory, and desktop F5 would have Evince with the current result, or something like that.
The desktops "down the split" of the keyboard are 6, T, G, and B; these hold Chrome, Firefox, Thunderbird, and Pidgin respectively. A ("audio") often has Clementine, though recently I've been using my laptop for sound since it can run Spotify. (The desktop's libc is too old.) Desktop I gets throwaway tasks.
I usually have three or four tasks going on that I return to within the span of a couple days, so that's usually around 8-10 desktops in use there (2 or 3 per task). Add in the 4 "fixed" desktops (web/mail/chat) and the scratch desktop and you're at 13-15 desktops usually in use.
Essentially what this gets is an easy way to go directly to the program that you want using keyboard shortcuts. (Well, it's easy as long as you don't forget what desktop it's on.:-p That happens occasionally.) The fact that it is a tiling WM is somewhat orthogonal to this issue: I could do the same thing with Gnome or KDE or whatever. But once you can call up whatever program you want immediately by changing desktops, that works better than overlapping most of the time IMO, so if you're going to rarely use overlapping windows, why not just go with a tiling WM?
This is related to what I'm looking into now. I don't need something quite professional-printing level, but with that in mind I'm looking at Asciidoc. (If you know about Markdown and not Asciidoc, they are similar-in-spirit markup languages. Both aim to be lightweight and something that if you have to read the source of, it's actually not too bad.)
Asciidoc has tool that output HTML and DocBook XML directly; that DocBook can then be compiled to EPUB or PDF or whatever (or as an alternate route to HTML).
I'm not as happy with the PDF output as I am with a Latex version of those documents, but it's hard to put my finger on why in many cases, and in many others it's probably just changing some of the typesetting preferences. But I'm much happer with the HTML output. I haven't yet tried EPUB.
Re-read what I said. What percentage of Gnome users have a keyboard without a Windows key? 1%? I suspect that's pretty generous. What I said is that I don't think that even defaults should be set for such a small population. It should still be easy to change though.
If facebook should be outlawed for having software that does that, then by extension, it should be illegal for humans to do the same thing.
By that logic, because the military is allow to possess nuclear weapons, so should you be.
Of course, the circumstances are far different in each case, just as they are with Facebook. I'm not totally on Germany's side here... privacy nowadays is a really thorny issue.
Take GPS tracking. Should cops be allowed to stick a GPS tracker on your car just for the heck of it? Imagine if they did that to everyone in town. (And were really good about it and no one noticed.) They let people drive for a few months, then sent out a few hundred thousand dollars of tickets to everyone. Privacy violation? Should it be legal?
They weren't really doing much that the police couldn't do without GPS. You could have cops tail each person and record all their moves. Have a few of them so that they can switch off so that the person being followed doesn't know it.
Of course, you couldn't actually do that: there are too many practical problems. You'd need an order of magnitude more cops than subjects. Think the people in town wouldn't notice an influx of new people? You'd need the cops to be highly trained and diligent. And who would pay?
(Just like how you could hire an army to go through and manually tag all your photos, but you can't practically speaking.)
But in the end, a GPS device is just emulating a few cops who are good at tailing someone. The latter is legal without a warrant, so why shouldn't the former be?
What it boils down to is that how easy it is to do something matters. It matters a lot. And I think it's certainly reasonable -- perhaps necessary -- to put some legal checks on some of this "privacy busting" technology. Where that line should go... I have no idea.
In windows, and as time goes on, in Linux, the Windows key is reserved for the OS, so the apps can safely use control (and to a lesser extent ALT).
That's exactly how I view things too. (With the exception that I run a virtual desktop program and it gets some Windows key shortcuts. But I view that as not really an exception after all.)
I do the same thing as you, maybe except for your treatment of alt. The program gets that too under my setups.
The latter. In particular, hitting the windows key opens the "overview", which is the replacement for the Gnome menus combined with a type-to-search bar and tonnes of transparent eye candy. The alternative is to move your mouse to the top left corner of your leftmost monitor, and wait. I'm sure changing it is possible, but they sure hasn't made it easy.
Then that sucks.
Nor provided sane defaults that doesn't require a 104/105-key keyboard.
See, here is where we disagree: I think the win key is the sane default (provided you present a reasonable way to change it).
I may be biased by my window manager setup, but the way I view thing nowadays is that programs should get the ctrl, alt, and shift modifiers, and the WM should get shortcuts involving the Windows key.
This is not a Taskbar vs Dock issue. The issue is that in OSX the act of closing a window does not equate to closing a program. This is why so many Windows users new to OSX mistake the Dock for leaving programs running when in Windows clicking the red X means quit. In OSX the user has to specifically choose Quit from the menu bar, right click on the icon in the Dock and select Quit, or press Command-Q. Whether this is a good idea is another debate topic.
I don't think that this was the point the OP was trying to make. I read his argument as that the dock has you do the same action -- clicking on an application icon -- both to start a program and also to raise it if it's already open. Sure, the indication is a little different -- the dock displays a little marker or whatever it does to indicate a program is running -- but it's not a [i]big[/i] change, and fundamentally you're taking the same action in both cases.
I only agree with this a tiny bit, but I'm pretty sure that's what he was trying to say.
And Windows 7 does go that way, but you can (thankfully, or I might be spending a lot more time in Linux at home) change that behavior and bring back the old "separate taskbar entry for each window" view. The only thing that changes is if you have pinned stuff, it shows up in the middle of your window icons instead of in the dedicated quick launch area. And it makes a much bigger difference between what the icon looks like when the program is already running and when it's not.
(And because I'm opinionated, on your last sentence I quoted, it's not.:-))
I whole-heartedly second this comment. I'm pretty ambivalent about the "dedicated quickstart area" vs "pinning" and some of the features, but some others of the other changes are great. The ability to show a progress bar in your window's taskbar area is something that all WMs should copy.
But the default view, where it compresses all of an application's windows into "one" icon, sucks. It's bringing many of the worst obnoxious aspects of the OS X dock to the taskbar.
The one place I will back off this stance is low-resolution screens. My laptop is 1024x768, and I use the default view there; I like it more than both the Win 7 more-classic option and the combining steps taken by XP.
I don't have Windows keys on my keyboard. The shortcuts assume that you do. Well, Gnome 3 devs, if you really like Windows that much, run it!
That's a bit of a silly stance, even taken somewhat in jest. I use the Windows key more when I'm in Linux than I do in Windows. (It controls my window manager, where it belongs, and... let's just say that xmonad has more operations that I can usefully do with a keyboard than Windows does. In particular, win- changes to the virtual desktop named by that key, and I use a lot of virtual desktops.)
Not having used Gnome 3, I don't know what it does. Does it just default the shortcuts to use Windows, or does it not let you (or make it difficult) to change them?
I personally think that the former is just fine (you optimize for the common case -- and nowadays, nearly everyone has a Windows key), and that the latter is inexcusable.
Yeah, I'm continually surprised that his choices are so... conventional. I don't mean that in a bad way, I'm just surprised. I run Windows on my home desktop by choice, have defended many aspects of it a lot over the years here and elsewhere... and even I run xmonad when I'm on a Linux system I use more than momentarily.
And BTW, Intel's compiler (version 11) produces code that's more like what it expects. For the six temporaries, it uses registers for everything but one (not sure what is going on there):
call get movl %eax, %edi// a call get movl %eax, (%esp)// b call get movl %eax, %esi// c call get movl %eax, %ebp// d call get movl %eax, %ebx// e call get pushl %eax// eax holds f from the call pushl %ebx// ebx was e pushl %ebp// ebp was d pushl %esi// esi was c movl 16(%esp), %eax// b was in memory for whatever reason pushl %eax pushl %edi// edi is a call use
Yes, that's true: the problem was rather more acute historically. A lot of C's decisions where we'd say "things would be way better if they had done things this way" were probably correct at the time; I think that null-terminated strings are another.
And I was under the impression you weren't supposed to use esi and edi as tmp stores or as the output of an expr.
They are totally fine to use as temporary registers. The main catch is that the string instructions (like stosd, usually prefixed with rep) use those registers as part of their contract. But it's to do stuff you'd have in a register anyway.
If you compile this function:
void foo() {
int a = get(), b = get(), c = get(), d = get(), e = get(), f = get();
use(a, b, c, d, e, f); }
with GCC -O3 (this is with -m32, otherwise it will use the new x64 registers), you'll get this out (remember, in AT&T syntax, data flows left-to-right):
call get
movl %eax, -20(%ebp)// a is stored in memory at ebp-20
call get
movl %eax, -16(%ebp)// b is stored in memory at ebp-16
call get
movl %eax, %edi// c is stored in edi
call get
movl %eax, %esi// d is stored in esi
call get
movl %eax, %ebx// e is stored in ebx
call get
movl %ebx, 16(%esp)// populate the argument slots (this is e)
movl %esi, 12(%esp)// d
movl %edi, 8(%esp)// c
movl %eax, 20(%esp)// eax still holds the return from the last call, so this is f (don't know why it's so late)
movl -16(%ebp), %eax// ebp-16 is b; load it, then write back to the argument slot
movl %eax, 4(%esp)
movl -20(%ebp), %eax// ebp-20 is a; load it, then write back to the argument slot
movl %eax, (%esp)
call use
In other words, GCC has no compunction about using edi and esi as temporary storage for c and d. I don't know why a and b go into memory though, to be honest, and not into ecx and edx. The registers are open. It's a little strange.:-)
Oh, I fully agree. But the one that matters for safety purposes (at least sidestepping the "a multi-byte sequence got cut off in the middle" problem) is the byte count, not the logical character count. And safety is why, the argument goes, we'd have been better off with counted strings.
(In fact, even "get me the number of logical characters" isn't unambiguious. Is it the number of Unicode code points, or the number of glyphs? I.e. do you count "combining acute accent" followed by "e" as one or two characters? It's two code points, but to the character it's only one. So there's at least three.)
Slashdot Mirror
Otherwise how would caring about single window mode require one to be a Windows drone?
"Require" is a strong word, but my long-term impression of the Gimp is that it is fine if you can give it its own virtual desktop, and moderately unusable if you can't.
Practically speaking, what that translates to is that it works fine in Linux and is moderately unusable in Windows; not many people have a virtual desktop application for Windows. (They do exist, and are definitely usable, but they aren't as smooth as WMs on Linux.)
Things are better than they used to be though. I'm not sure about this because I haven't used it in a while, but I think the Gimp will now raise all its tool windows when you raise one. Before that it was almost completely unusable if you couldn't devote a virtual desktop.
I disagree. Is there really some super-pressing feature that you can't wait a couple more days for .8? And what if you don't call crypt(), but some library you're using does? Are you that familiar with all of your code base? And what about in the future? What if in 6 months you decide to use crypt(), are you going to remember about this bug? (Hopefully you'd notice that your logins are always successful.)
I'm not necessarily saying it should be totally unavailable, but I don't think it should be particularly easy to get to.
(Or maybe I would consider replacing the download with one that unzips to a couple additional higher level directories: this_release_has_a_buggy_crypt/read_security.txt_first/.)
This is not correct.
Ondrej's post you link to is specifically referring to the patched version of PHP that you get from the Debian repository. One of the patches Ondrej applies makes PHP use the system crypt(). Without that patch -- with the stock PHP code -- PHP uses its own crypt(). Now, other distributions might apply Ondrej's patch, but I certainly wouldn't count on it, and you definitely will have a broken crypt() if you get the stock PHP.
For my source, I again cite an email from Ondrej, this time to the PHP list http://marc.info/?l=php-internals&m=131404279532421&w=2
In that email, he suggests to the PHP folks that they should apply his patch.
Worked in Software Dev & Support for 12 years. Never once seen a Regression test find something that is broken
I think you're full of BS. In fact, this particular bug was found by a regression test; just no one noticed because they have so many failing tests because their process is non-existent.
Oh, and not only is the project's QA apparently nonexistent (not that they're the only big project that doesn't have useful tests), they also don't have any sense when it comes to their website. OK, they posted a message that 5.3.7 has a severe security bug on their front page; that's a good start.
But they then should have pulled the release, and made it deliberately difficult to get to. They didn't. If you Google "PHP", the second link is to their download page, and you can grab 5.3.7 from there without ever seeing that warning.
I'm pretty sure that the project is run by a bunch of 12 year olds.
it's not the bug in the library function that caused him to say that
OK, reading the thread again I may be projecting. But that's my take on the situation anyway.
I think that the post you replied to was a bit extreme, but it's not the bug in the library function that caused him to say that: it's the fact that the PHP project lacks the testing infrastructure that any reasonable project of that size would have.
Anyone can commit a bug; that's easy and excusable. What makes it look like PHP is developed by a bunch of 12 year olds is the fact that they have a test suite with a test that exhibited the bug, and yet no one ran it before they made a release, because they've got too many failing tests so it just got swamped in with that noise.
I'm working on some dinky pieces of research software, and while we probably don't have as extensive a test suite as PHP does, we have a way better testing regimen. A project like PHP should have a CI server that runs their tests at least nightly, and a release shouldn't be made while there are failing tests. That's what expected failures are for. (They even know about expected failures, but still have over 200 failing tests for some reason.) Even we've got that.
It's the QA that's messed up, not the coding.
Since when did the FreeRunner or N900 use an OS and kernel under the GPLv3?
Huh? I never said they did. Unless you want to argue that being GPLv2 means that something isn't 'free as in speech'.
Impossible? No, look at the FreeRunner. (Or to a lesser extent, the N900.)
But likely? I think no. I honestly think that Android would not be in nearly the place that it is in right now the phone manufacturers were not able to lock them down. The phone manufacturers are probably relatively indifferent on their own, but the carriers love the fact that they are locked down, and that's where a lot of the real power lies. If Verizon and AT&T say "no, your platform is too open, we're not going to promote or subsidize your phones (it makes it harder to prevent tethering and upsell stuff)", how many of those phones would be sold?
I'm not saying it necessarily would play out that way, but at least if you look at market share, I think it's entirely possible that in a world with actual open phones, the benefactors would be the iPhone and WinMo.
The engineer in charge of the offices I once worked at kept the thermostat at 65 degrees "to save energy". Didn't matter that it was the middle of the summer with the AC going full blast and all the secretaries wearing sweaters.
It is hypothetically possible that he's correct. I recently learned that several buildings on the University I go to have what's called a "reheater" system. All air entering the building is cooled to 55 degrees in order to drop the humidity -- then is reheated back to whatever the thermostat setting is. Lowering the temperature on the thermostat doesn't cost any extra A/C, and saves on heating.
Probably not what was going on in your case, but theoretically possible, and an interesting tidbit in any case.
I'm pretty sure that, my first time through, I had a guy in my team on the last mission named "backup assault 23".
And that was on easy.
It can be used on multiple monitors and supports at least 9 virtual desktops.
I have... 27 virtual desktops available, and it has no problem with that. (These are shortcut to Win + 0-9, F1-F12, A, I, and T, G, and B (for those last three, think about a split keyboard).) Though usually only half or so are actually being used.
Basically for me, one desktop gets one or two windows. (Often this is Emacs and a terminal.) Windows that are related by task beyond that get nearby desktops: desktop F4 may be an Emacs window with a Latex document alongside a terminal in that directory, and desktop F5 would have Evince with the current result, or something like that.
The desktops "down the split" of the keyboard are 6, T, G, and B; these hold Chrome, Firefox, Thunderbird, and Pidgin respectively. A ("audio") often has Clementine, though recently I've been using my laptop for sound since it can run Spotify. (The desktop's libc is too old.) Desktop I gets throwaway tasks.
I usually have three or four tasks going on that I return to within the span of a couple days, so that's usually around 8-10 desktops in use there (2 or 3 per task). Add in the 4 "fixed" desktops (web/mail/chat) and the scratch desktop and you're at 13-15 desktops usually in use.
Essentially what this gets is an easy way to go directly to the program that you want using keyboard shortcuts. (Well, it's easy as long as you don't forget what desktop it's on. :-p That happens occasionally.) The fact that it is a tiling WM is somewhat orthogonal to this issue: I could do the same thing with Gnome or KDE or whatever. But once you can call up whatever program you want immediately by changing desktops, that works better than overlapping most of the time IMO, so if you're going to rarely use overlapping windows, why not just go with a tiling WM?
It's not for everyone, but I like it a lot.
This is related to what I'm looking into now. I don't need something quite professional-printing level, but with that in mind I'm looking at Asciidoc. (If you know about Markdown and not Asciidoc, they are similar-in-spirit markup languages. Both aim to be lightweight and something that if you have to read the source of, it's actually not too bad.)
Asciidoc has tool that output HTML and DocBook XML directly; that DocBook can then be compiled to EPUB or PDF or whatever (or as an alternate route to HTML).
I'm not as happy with the PDF output as I am with a Latex version of those documents, but it's hard to put my finger on why in many cases, and in many others it's probably just changing some of the typesetting preferences. But I'm much happer with the HTML output. I haven't yet tried EPUB.
Re-read what I said. What percentage of Gnome users have a keyboard without a Windows key? 1%? I suspect that's pretty generous. What I said is that I don't think that even defaults should be set for such a small population. It should still be easy to change though.
If facebook should be outlawed for having software that does that, then by extension, it should be illegal for humans to do the same thing.
By that logic, because the military is allow to possess nuclear weapons, so should you be.
Of course, the circumstances are far different in each case, just as they are with Facebook. I'm not totally on Germany's side here... privacy nowadays is a really thorny issue.
Take GPS tracking. Should cops be allowed to stick a GPS tracker on your car just for the heck of it? Imagine if they did that to everyone in town. (And were really good about it and no one noticed.) They let people drive for a few months, then sent out a few hundred thousand dollars of tickets to everyone. Privacy violation? Should it be legal?
They weren't really doing much that the police couldn't do without GPS. You could have cops tail each person and record all their moves. Have a few of them so that they can switch off so that the person being followed doesn't know it.
Of course, you couldn't actually do that: there are too many practical problems. You'd need an order of magnitude more cops than subjects. Think the people in town wouldn't notice an influx of new people? You'd need the cops to be highly trained and diligent. And who would pay?
(Just like how you could hire an army to go through and manually tag all your photos, but you can't practically speaking.)
But in the end, a GPS device is just emulating a few cops who are good at tailing someone. The latter is legal without a warrant, so why shouldn't the former be?
What it boils down to is that how easy it is to do something matters. It matters a lot. And I think it's certainly reasonable -- perhaps necessary -- to put some legal checks on some of this "privacy busting" technology. Where that line should go... I have no idea.
In windows, and as time goes on, in Linux, the Windows key is reserved for the OS, so the apps can safely use control (and to a lesser extent ALT).
That's exactly how I view things too. (With the exception that I run a virtual desktop program and it gets some Windows key shortcuts. But I view that as not really an exception after all.)
I do the same thing as you, maybe except for your treatment of alt. The program gets that too under my setups.
The latter. In particular, hitting the windows key opens the "overview", which is the replacement for the Gnome menus combined with a type-to-search bar and tonnes of transparent eye candy. The alternative is to move your mouse to the top left corner of your leftmost monitor, and wait. I'm sure changing it is possible, but they sure hasn't made it easy.
Then that sucks.
Nor provided sane defaults that doesn't require a 104/105-key keyboard.
See, here is where we disagree: I think the win key is the sane default (provided you present a reasonable way to change it).
I may be biased by my window manager setup, but the way I view thing nowadays is that programs should get the ctrl, alt, and shift modifiers, and the WM should get shortcuts involving the Windows key.
This is not a Taskbar vs Dock issue. The issue is that in OSX the act of closing a window does not equate to closing a program. This is why so many Windows users new to OSX mistake the Dock for leaving programs running when in Windows clicking the red X means quit. In OSX the user has to specifically choose Quit from the menu bar, right click on the icon in the Dock and select Quit, or press Command-Q. Whether this is a good idea is another debate topic.
I don't think that this was the point the OP was trying to make. I read his argument as that the dock has you do the same action -- clicking on an application icon -- both to start a program and also to raise it if it's already open. Sure, the indication is a little different -- the dock displays a little marker or whatever it does to indicate a program is running -- but it's not a [i]big[/i] change, and fundamentally you're taking the same action in both cases.
I only agree with this a tiny bit, but I'm pretty sure that's what he was trying to say.
And Windows 7 does go that way, but you can (thankfully, or I might be spending a lot more time in Linux at home) change that behavior and bring back the old "separate taskbar entry for each window" view. The only thing that changes is if you have pinned stuff, it shows up in the middle of your window icons instead of in the dedicated quick launch area. And it makes a much bigger difference between what the icon looks like when the program is already running and when it's not.
(And because I'm opinionated, on your last sentence I quoted, it's not. :-))
I whole-heartedly second this comment. I'm pretty ambivalent about the "dedicated quickstart area" vs "pinning" and some of the features, but some others of the other changes are great. The ability to show a progress bar in your window's taskbar area is something that all WMs should copy.
But the default view, where it compresses all of an application's windows into "one" icon, sucks. It's bringing many of the worst obnoxious aspects of the OS X dock to the taskbar.
The one place I will back off this stance is low-resolution screens. My laptop is 1024x768, and I use the default view there; I like it more than both the Win 7 more-classic option and the combining steps taken by XP.
I don't have Windows keys on my keyboard. The shortcuts assume that you do. Well, Gnome 3 devs, if you really like Windows that much, run it!
That's a bit of a silly stance, even taken somewhat in jest. I use the Windows key more when I'm in Linux than I do in Windows. (It controls my window manager, where it belongs, and... let's just say that xmonad has more operations that I can usefully do with a keyboard than Windows does. In particular, win- changes to the virtual desktop named by that key, and I use a lot of virtual desktops.)
Not having used Gnome 3, I don't know what it does. Does it just default the shortcuts to use Windows, or does it not let you (or make it difficult) to change them?
I personally think that the former is just fine (you optimize for the common case -- and nowadays, nearly everyone has a Windows key), and that the latter is inexcusable.
Yeah, I'm continually surprised that his choices are so... conventional. I don't mean that in a bad way, I'm just surprised. I run Windows on my home desktop by choice, have defended many aspects of it a lot over the years here and elsewhere... and even I run xmonad when I'm on a Linux system I use more than momentarily.
And BTW, Intel's compiler (version 11) produces code that's more like what it expects. For the six temporaries, it uses registers for everything but one (not sure what is going on there):
Yes, that's true: the problem was rather more acute historically. A lot of C's decisions where we'd say "things would be way better if they had done things this way" were probably correct at the time; I think that null-terminated strings are another.
And I was under the impression you weren't supposed to use esi and edi as tmp stores or as the output of an expr.
They are totally fine to use as temporary registers. The main catch is that the string instructions (like stosd, usually prefixed with rep) use those registers as part of their contract. But it's to do stuff you'd have in a register anyway.
If you compile this function:
with GCC -O3 (this is with -m32, otherwise it will use the new x64 registers), you'll get this out (remember, in AT&T syntax, data flows left-to-right):
In other words, GCC has no compunction about using edi and esi as temporary storage for c and d. I don't know why a and b go into memory though, to be honest, and not into ecx and edx. The registers are open. It's a little strange. :-)
Oh, I fully agree. But the one that matters for safety purposes (at least sidestepping the "a multi-byte sequence got cut off in the middle" problem) is the byte count, not the logical character count. And safety is why, the argument goes, we'd have been better off with counted strings.
(In fact, even "get me the number of logical characters" isn't unambiguious. Is it the number of Unicode code points, or the number of glyphs? I.e. do you count "combining acute accent" followed by "e" as one or two characters? It's two code points, but to the character it's only one. So there's at least three.)
OK, but then why single out strcpy? How's it different from almost any other operation?