Are you sure Alpine supports it? It may be there, but it's not a feature I've come across. (I do know there's a feature in Alpine called "bounce", but that does something different — that's basically the same as "forward", only it sends the mail entirely unchanged (as if it came from the original sender straight to the forwardee)).
However, this still isn't as fully-general as a true transactional FS. Other processes running your program now cannot (legally) read the protected file if the lock file exists. This means that you can't have a long-running transaction, which you might want to do if you want to be able to read a consistent image for a long period of time.
Not to mention what happens if your process crashes (or is killed) after it's obtained the lockfile, but only half way through updating the data...
It depends what you mean by "Windows". The kernel itself is largely written in C (and some assembler). A lot of the user-level libraries (MFC etc) are written in C++, as are many of the core applications. Which of these count as "Windows" is a question of definition:-)
That's weaselly in a number of ways - not just the fact that few people will read it or realise its significance until they have a reason to sue Sony (and consult a lawyer), but also the fact that the choice is between "you must use arbitration and waive all rights to class action", and "never resolve disputes with any Sony entity via arbitration". No thanks - I'd prefer to hang on to my right to choose whether to enter arbitration or not, or pursue a class action or not, based on the nature of the dispute...
For example, if I make a donation in December for $10,000, but as of Jan 1 the charity has still not reached it's goal and the money has not been collected, can I still count that as a deduction? What if it reaches it's goal before I file my taxes? Is it a 2011 or a 2012 deduction? What if it never reaches it's goal? There aren't simple answers to these questions,
Count it as a deduction on the date the money is taken from your card. Before that date you can't reasonably call it a donation, because you still have the money. And afterwards, you know that the funding has gone through.
No, even over in the US, this Brit doesn't see any adverts for things other than the BBC itself. As expected.
Actually you do sometimes get adverts if you're accessing the BBC news website from an IP address that's "outside the UK" - both sidebar adverts and little videos that play before the video you actually want to watch. (For my work I connect to the internet via a VPN that terminates in the US or in the Netherlands, and hence I get to see the adverts even though I'm in the UK...)
Well unless I am mistaken the current pope used to be the guy in charge of the coverups? Ergo the leadership of this organization knew about the cover ups and were somewhat involved with them.
You're making too many assumptions. First, there was only a central organisation to investigate abuse since 2001:
Prior to 2001, the primary responsibility for investigating allegations of sexual abuse and disciplining perpetrators rested with the individual dioceses. In 2001, Ratzinger convinced John Paul II to put the Congregation for the Doctrine of the Faith in charge of all investigations and policies surrounding sexual abuse in order to combat such abuse more efficiently.
Pope Paul VI - the one we're talking about - died in 1978. So while it's not impossible that he knew something, "undeniable fact" is stating the case too strongly.
some keyboards not actually having a backspace key
Close, but not quite... it's more to do with the difficulty of getting the backspace/delete/erase/etc keys to work properly on all the different varieties of terminal that Unix and other OSs used to support: it was very common to have the settings on the computer not match up with your terminal, in such a way that pressing the "delete" key would not delete but instead produce ^H or ^? or some other control sequence...
Actually Peter Pan was not in the public domain when Disney created their film - they had to license it. But the rest of your point stands nonetheless:)
There's nothing inherently offensive about any act. Therefore 'offending' is not something you can do.
Similarly there's no inherent meaning to any words. They're just sounds, or bunches of letters. And yet we can still communicate... and exchange information. And ask for things. And praise, and criticise. And offend. Just because a meaning is assigned by people doesn't mean it's not real.
Phrasing it in the usual way makes it sound like the onus is on individuals not to do anything offensive.
If you shoot someone with a gun, that will cause them some harm. The onus is on you not to cause that harm—unless there's a good reason to do so, such as stopping them killing you. The same goes with being offensive: sometimes it's necessary, but usually it can be avoided without unduly impinging on your life—and the onus is on you to do so.
There are three data channels, but they all just carry data. They are not dedicated to any specific color. Digital crosstalk would just cause noise, and an incompletely reproduced image.
Actually that's not true: data0 is blue, data1 is green, and data2 is red - at least in DVI mode (see the DVI pinout and note that DVI and HDMI are electrically compatible, and you can use passive adapters to convert the two, at least for standard video modes).
You went around three times, increasing your contribution to traffic volume by a factor of three, but you "didn't block up traffic"?
Unless the traffic was heavy, then no, they wouldn't have blocked up traffic, because the other drivers (behind them and elsewhere) who knew where they were going would not be held up by them for more than a fraction of a second: the number of "slots" available for cars to navigate the roundabout is typically larger than the number of cars needing to use them (which makes them flow well - of course when it's busy and most/all of the slots are used it's a different story). Whereas at a four-way stop or traffic light, if they'd stopped to look at the map they would have held up every single driver behind them.
(I don't actually recommend going round a roundabout multiple times, but when people occasionally do it doesn't usually cause much of an inconvenience.)
When traffic is moving at highway speeds and there are no backups, it makes sense to move sooner to the lane that will remain open through construction.
(source: the article you linked to). In other words, if traffic is flowing smoothly, keep it flowing smoothly by merging smoothly (and early). (Of course, once traffic is stationary and backed up, then it makes sense to use both lanes, because not doing so just doubles the length of the tailback. But that's not the situation that the GP was referring to:-)
Perhaps like onramps in the U.S., for peak traffic they need to install entrance lights that would prevent entry in waves from various sides, and give side traffic a chance to get in.
They do actually do this on some larger roundabouts in the UK, and it works pretty well on the whole.
But 90% fewer fatalities on 500% more accidents is, what?
It's 90% fewer fatalities. (The figure for fatalities is per year, not per accident. And even if it weren't, a 90% lower fatality rate on 500% more accidents is still a 40% reduction in fatalities overall. Sounds good to me!).
And yes, I pulled that 500% out of my behind;
The article linked by the GP claims 40% fewer accidents overall, and actually links to a source. The effect is probably twofold—for drivers that know how to use them, they're safer by design, and those that don't take a lot more care—so the accident rate is reduced either way.
Sounds weird to me (if I find something wrong in week 1 of dev, I want to fix it now, not plow through and go back later)...
This makes sense to me - provided it's used for the right kind of cases. The case it'll likely apply to best is when, during a coding phase, you discover you don't know whether the widget should be red or yellow. Your alternatives are to:
Enquire from the appropriate people (business sponsor, customer, stakeholder etc) what the right colour is—only to get caught up in discussions over whether the widget should actually be blue, and in fact should be square and not circular, and could you possibly make it blink twice when I move the mouse over it?... or...
Just make it red for now, but keep a note to raise this next time you are having conversations with the customer
The idea is that, by taking the second option, you keep making progress on the parts of the spec that you are sure about, rather than losing focus and being diverted onto endless discussions about minor matters.
I just read the GPLV3 and don't find a clear statement that you must be able to run the modified source code on the same system upon which the modified object code has been received. You must get source, yes. Must execute, I don't see.
“Installation Information” for a User Product means any methods, procedures, authorization keys, or other information required to install and execute modified versions of a covered work in that User Product from a modified version of its Corresponding Source. The information must suffice to ensure that the continued functioning of the modified object code is in no case prevented or interfered with solely because modification has been made.
Second, doesn't the GPL specifically deny any warrantee of any kind, even for "usability and fitness of purpose" or whatever, to anyone who modifies the code? If you modify the code and try to install it and it does not run, doesn't the GPL specifically release the provider from ANY requirement to support the modified code? Doesn't that mean "if you change it and it doesn't run, tough luck?"
Not quite. That disclaimer is saying "if the code doesn't perform in the way you want, you can't hold us responsible", and it applies whether you modify the code or not. There's a big difference between being able to run the code and it not working, and it not running at all. In the first case, if it doesn't work as I like, I can fix it. In the second case, I can't, and this is exactly what the GPL is designed to prevent.
I would be very scared of any code that says anything other than that last bit. I write code and send it off to other people, and routinely they are unable to get the unmodified code to work properly. The interface to something has changed, the database they are using is just a tiny bit different. So if GPLV3 says I must distribute anything I modify and MUST SUPPORT other people getting it to run, whether or not they changed anything, that's just too much of an exposure to accept. Yes, I know, if it is true, don't use GPLV3 code. But is it true?
No, it's not true. You don't have to guarantee that the code will work, in the sense of being free from bugs, but if you're distributing someone else's GPLv3 code, then you do have to guarantee that they can at least compile and run it... once it's running, it's up to them whether it works or not.
Now, I understand that not providing the modified source is a violation, but does GPLV3 really make not being able to run code on a specific device a violation, too?
If you sold the device with the GPLv3 code running on it, and won't let other people do the same with their modified versions, then yes.
Maybe because bash is installed by default on most Linux/UNIX systems and is portable across all yoru installed base.
perhaps they exist but in 20 years I've not see a Linux distro without Perl.
I've seen many. Usually they are embedded systems, where memory is at a premium.
Or maybe your security requirements disallow python, or ruby or whatever to be installed.
if they disallow perl then shell needs to be disallowed too
Nonsense. From a security point of view there's a lot of sense in minimising the amount of code on a system. If you have bash and perl running, and someone discovers a vulnerability in perl, you're wide open. If you just have bash, you're not. Of course, the same applies the other way round too - but there is a strong security argument for having "less stuff" installed and running wherever possible.
Or that running shell scripts using many built-ins run faster than the interpreted languages?
this is patently false. Perl is vastly faster than shell even taking into account load times when you do anything significant. Bash scripts that do anthing important generally are calling things like awk and grep and sed to parse things and these invocations are dramatically slower in a loop than a single invocation of perl. Additionally, perl I/O is in many case faster than standard unix operations that move large blocks of data.
finally invoking and disposing a command like awk many times in a row makes for very poor memory management and system resource utilization compared to keeping one program like perl resident.
So don't try to argue this on speed or system resource utilization.
You're right that it's not a hands-down win for bash, not by a long way. But there are tradeoffs - for instance, in embedded systems (once again), the footprint of bash alone is much smaller than that of bash+perl.
Bash scripting features seem to stay more stable over time vs. other scripting languages that are constantly changing.
huh? perl is very static and backward compatible.
moreover, it's the helped commands that bash needs like grep and awk and so many other system resource introspection calls that one cannot count on being present or taking exactly the ame arguments.
even a braindead command like "cp" is not only different on Linux and BSD but it's command arguments have changed over time. Whereas is perl the commands needed to copy files have not changed in 20 years.
You do have a point here - but then, copying a file in perl is rather more work than it is in bash (especially once you take into account error checking, recursive copying etc...)
The app teams within your company may want to constantly upgrade the installed version that might break you scripts/programs.
the only time i've seen broken perl was the 5.8 to 5.10 switch changed the timing of a few things.
Were you not around for the perl4->5 change? That broke scripts... though to be fair I don't really see this as an argument either way, because bash (and the utilities called from it) change from time to time too...
And bash is dirt simple to learn and implement for non-programmers.
Perl is very very very close to bash in syntax
I actually disagree that bash is very simple to learn for non-programmers. It's very easy to write simple scripts that appear to work, but break if they're passed a parameter containing a space or an asterisk. In this respect perl is better - it is (by design) much less vulnerable to special characters in input. But I also disagree that the syntax is very close to bash - superficially there are a lot of dollar signs in both, and the quoting *looks* similar, but that's about as far as it goes...
It's like how you can use the same equations to predict the movements of two billiard balls as with a million. They're still all within the parameters (speed, size, etc), there's just more balls.
How does any of that rule out the possibility that there is not another factor, whose effects are too small to observe within a small number of generations (in the same way that relativistic effects to apply at everyday speeds, but are too small to measure)? I'm not saying I believe that such an effect exists - or even that we should assume that it does - but I am saying that a good scientist knows the limits of his or her knowledge: it's one thing to hypothesise that an effect observed on small scales exists at larger scales, and scales up accordingly - but until that has been tested it is just that - a hypothesis (although that doesn't stop it being the most rational thing to believe!). When it comes to extrapolating beyond the data, experience proves it's never a has to:-)
Slashdot Mirror
Why involve cat at all? gunzip file1 | whatever
That command - I do not think it means what you think it means. Try: gunzip < file1 | whatever
I know what you mean, but it hasn't stopped them talking about "web pages" :-)
Are you sure Alpine supports it? It may be there, but it's not a feature I've come across. (I do know there's a feature in Alpine called "bounce", but that does something different — that's basically the same as "forward", only it sends the mail entirely unchanged (as if it came from the original sender straight to the forwardee)).
However, this still isn't as fully-general as a true transactional FS. Other processes running your program now cannot (legally) read the protected file if the lock file exists. This means that you can't have a long-running transaction, which you might want to do if you want to be able to read a consistent image for a long period of time.
Not to mention what happens if your process crashes (or is killed) after it's obtained the lockfile, but only half way through updating the data...
To my knowledge, Windows was/is built in C++.
It depends what you mean by "Windows". The kernel itself is largely written in C (and some assembler). A lot of the user-level libraries (MFC etc) are written in C++, as are many of the core applications. Which of these count as "Windows" is a question of definition :-)
But a lot of Europeans know English pretty well despite never having set foot in America.
This is true. The majority of British people, for a start ;-)
Yes - the two companies have a joint venture that produces mobile phones, but they haven't merged.
That's weaselly in a number of ways - not just the fact that few people will read it or realise its significance until they have a reason to sue Sony (and consult a lawyer), but also the fact that the choice is between "you must use arbitration and waive all rights to class action", and "never resolve disputes with any Sony entity via arbitration". No thanks - I'd prefer to hang on to my right to choose whether to enter arbitration or not, or pursue a class action or not, based on the nature of the dispute...
For example, if I make a donation in December for $10,000, but as of Jan 1 the charity has still not reached it's goal and the money has not been collected, can I still count that as a deduction? What if it reaches it's goal before I file my taxes? Is it a 2011 or a 2012 deduction? What if it never reaches it's goal? There aren't simple answers to these questions,
Count it as a deduction on the date the money is taken from your card. Before that date you can't reasonably call it a donation, because you still have the money. And afterwards, you know that the funding has gone through.
No, even over in the US, this Brit doesn't see any adverts for things other than the BBC itself. As expected.
Actually you do sometimes get adverts if you're accessing the BBC news website from an IP address that's "outside the UK" - both sidebar adverts and little videos that play before the video you actually want to watch. (For my work I connect to the internet via a VPN that terminates in the US or in the Netherlands, and hence I get to see the adverts even though I'm in the UK...)
But beware, it expects a regular expression, not just text to search for.
Not in Firefox (sadly)...
ctrl+A -> ring bell, escape key for screen
Ctrl+A -> go to start of current line (in bash/tcsh/emacs)
Well unless I am mistaken the current pope used to be the guy in charge of the coverups? Ergo the leadership of this organization knew about the cover ups and were somewhat involved with them.
You're making too many assumptions. First, there was only a central organisation to investigate abuse since 2001:
Prior to 2001, the primary responsibility for investigating allegations of sexual abuse and disciplining perpetrators rested with the individual dioceses. In 2001, Ratzinger convinced John Paul II to put the Congregation for the Doctrine of the Faith in charge of all investigations and policies surrounding sexual abuse in order to combat such abuse more efficiently.
Pope Paul VI - the one we're talking about - died in 1978. So while it's not impossible that he knew something, "undeniable fact" is stating the case too strongly.
some keyboards not actually having a backspace key
Close, but not quite... it's more to do with the difficulty of getting the backspace/delete/erase/etc keys to work properly on all the different varieties of terminal that Unix and other OSs used to support: it was very common to have the settings on the computer not match up with your terminal, in such a way that pressing the "delete" key would not delete but instead produce ^H or ^? or some other control sequence...
Actually Peter Pan was not in the public domain when Disney created their film - they had to license it. But the rest of your point stands nonetheless :)
There's nothing inherently offensive about any act. Therefore 'offending' is not something you can do.
Similarly there's no inherent meaning to any words. They're just sounds, or bunches of letters. And yet we can still communicate... and exchange information. And ask for things. And praise, and criticise. And offend. Just because a meaning is assigned by people doesn't mean it's not real.
Phrasing it in the usual way makes it sound like the onus is on individuals not to do anything offensive.
If you shoot someone with a gun, that will cause them some harm. The onus is on you not to cause that harm—unless there's a good reason to do so, such as stopping them killing you. The same goes with being offensive: sometimes it's necessary, but usually it can be avoided without unduly impinging on your life—and the onus is on you to do so.
There are three data channels, but they all just carry data. They are not dedicated to any specific color. Digital crosstalk would just cause noise, and an incompletely reproduced image.
Actually that's not true: data0 is blue, data1 is green, and data2 is red - at least in DVI mode (see the DVI pinout and note that DVI and HDMI are electrically compatible, and you can use passive adapters to convert the two, at least for standard video modes).
You went around three times, increasing your contribution to traffic volume by a factor of three, but you "didn't block up traffic"?
Unless the traffic was heavy, then no, they wouldn't have blocked up traffic, because the other drivers (behind them and elsewhere) who knew where they were going would not be held up by them for more than a fraction of a second: the number of "slots" available for cars to navigate the roundabout is typically larger than the number of cars needing to use them (which makes them flow well - of course when it's busy and most/all of the slots are used it's a different story). Whereas at a four-way stop or traffic light, if they'd stopped to look at the map they would have held up every single driver behind them.
(I don't actually recommend going round a roundabout multiple times, but when people occasionally do it doesn't usually cause much of an inconvenience.)
You are wrong. Deal with it.
Actually you are wrong:
When traffic is moving at highway speeds and there are no backups, it makes sense to move sooner to the lane that will remain open through construction.
(source: the article you linked to). In other words, if traffic is flowing smoothly, keep it flowing smoothly by merging smoothly (and early). (Of course, once traffic is stationary and backed up, then it makes sense to use both lanes, because not doing so just doubles the length of the tailback. But that's not the situation that the GP was referring to :-)
Perhaps like onramps in the U.S., for peak traffic they need to install entrance lights that would prevent entry in waves from various sides, and give side traffic a chance to get in.
They do actually do this on some larger roundabouts in the UK, and it works pretty well on the whole.
But 90% fewer fatalities on 500% more accidents is, what?
It's 90% fewer fatalities. (The figure for fatalities is per year, not per accident. And even if it weren't, a 90% lower fatality rate on 500% more accidents is still a 40% reduction in fatalities overall. Sounds good to me!).
And yes, I pulled that 500% out of my behind;
The article linked by the GP claims 40% fewer accidents overall, and actually links to a source. The effect is probably twofold—for drivers that know how to use them, they're safer by design, and those that don't take a lot more care—so the accident rate is reduced either way.
Sounds weird to me (if I find something wrong in week 1 of dev, I want to fix it now, not plow through and go back later) ...
This makes sense to me - provided it's used for the right kind of cases. The case it'll likely apply to best is when, during a coding phase, you discover you don't know whether the widget should be red or yellow. Your alternatives are to:
The idea is that, by taking the second option, you keep making progress on the parts of the spec that you are sure about, rather than losing focus and being diverted onto endless discussions about minor matters.
I just read the GPLV3 and don't find a clear statement that you must be able to run the modified source code on the same system upon which the modified object code has been received. You must get source, yes. Must execute, I don't see.
It's there, in section 6:
Second, doesn't the GPL specifically deny any warrantee of any kind, even for "usability and fitness of purpose" or whatever, to anyone who modifies the code? If you modify the code and try to install it and it does not run, doesn't the GPL specifically release the provider from ANY requirement to support the modified code? Doesn't that mean "if you change it and it doesn't run, tough luck?"
Not quite. That disclaimer is saying "if the code doesn't perform in the way you want, you can't hold us responsible", and it applies whether you modify the code or not. There's a big difference between being able to run the code and it not working, and it not running at all. In the first case, if it doesn't work as I like, I can fix it. In the second case, I can't, and this is exactly what the GPL is designed to prevent.
I would be very scared of any code that says anything other than that last bit. I write code and send it off to other people, and routinely they are unable to get the unmodified code to work properly. The interface to something has changed, the database they are using is just a tiny bit different. So if GPLV3 says I must distribute anything I modify and MUST SUPPORT other people getting it to run, whether or not they changed anything, that's just too much of an exposure to accept. Yes, I know, if it is true, don't use GPLV3 code. But is it true?
No, it's not true. You don't have to guarantee that the code will work, in the sense of being free from bugs, but if you're distributing someone else's GPLv3 code, then you do have to guarantee that they can at least compile and run it... once it's running, it's up to them whether it works or not.
Now, I understand that not providing the modified source is a violation, but does GPLV3 really make not being able to run code on a specific device a violation, too?
If you sold the device with the GPLv3 code running on it, and won't let other people do the same with their modified versions, then yes.
Maybe because bash is installed by default on most Linux/UNIX systems and is portable across all yoru installed base.
perhaps they exist but in 20 years I've not see a Linux distro without Perl.
I've seen many. Usually they are embedded systems, where memory is at a premium.
Or maybe your security requirements disallow python, or ruby or whatever to be installed.
if they disallow perl then shell needs to be disallowed too
Nonsense. From a security point of view there's a lot of sense in minimising the amount of code on a system. If you have bash and perl running, and someone discovers a vulnerability in perl, you're wide open. If you just have bash, you're not. Of course, the same applies the other way round too - but there is a strong security argument for having "less stuff" installed and running wherever possible.
Or that running shell scripts using many built-ins run faster than the interpreted languages?
this is patently false. Perl is vastly faster than shell even taking into account load times when you do anything significant. Bash scripts that do anthing important generally are calling things like awk and grep and sed to parse things and these invocations are dramatically slower in a loop than a single invocation of perl. Additionally, perl I/O is in many case faster than standard unix operations that move large blocks of data.
finally invoking and disposing a command like awk many times in a row makes for very poor memory management and system resource utilization compared to keeping one program like perl resident.
So don't try to argue this on speed or system resource utilization.
You're right that it's not a hands-down win for bash, not by a long way. But there are tradeoffs - for instance, in embedded systems (once again), the footprint of bash alone is much smaller than that of bash+perl.
Bash scripting features seem to stay more stable over time vs. other scripting languages that are constantly changing.
huh? perl is very static and backward compatible. moreover, it's the helped commands that bash needs like grep and awk and so many other system resource introspection calls that one cannot count on being present or taking exactly the ame arguments.
even a braindead command like "cp" is not only different on Linux and BSD but it's command arguments have changed over time. Whereas is perl the commands needed to copy files have not changed in 20 years.
You do have a point here - but then, copying a file in perl is rather more work than it is in bash (especially once you take into account error checking, recursive copying etc...)
The app teams within your company may want to constantly upgrade the installed version that might break you scripts/programs.
the only time i've seen broken perl was the 5.8 to 5.10 switch changed the timing of a few things.
Were you not around for the perl4->5 change? That broke scripts... though to be fair I don't really see this as an argument either way, because bash (and the utilities called from it) change from time to time too...
And bash is dirt simple to learn and implement for non-programmers.
Perl is very very very close to bash in syntax
I actually disagree that bash is very simple to learn for non-programmers. It's very easy to write simple scripts that appear to work, but break if they're passed a parameter containing a space or an asterisk. In this respect perl is better - it is (by design) much less vulnerable to special characters in input. But I also disagree that the syntax is very close to bash - superficially there are a lot of dollar signs in both, and the quoting *looks* similar, but that's about as far as it goes...
It's like how you can use the same equations to predict the movements of two billiard balls as with a million. They're still all within the parameters (speed, size, etc), there's just more balls.
How does any of that rule out the possibility that there is not another factor, whose effects are too small to observe within a small number of generations (in the same way that relativistic effects to apply at everyday speeds, but are too small to measure)? I'm not saying I believe that such an effect exists - or even that we should assume that it does - but I am saying that a good scientist knows the limits of his or her knowledge: it's one thing to hypothesise that an effect observed on small scales exists at larger scales, and scales up accordingly - but until that has been tested it is just that - a hypothesis (although that doesn't stop it being the most rational thing to believe!). When it comes to extrapolating beyond the data, experience proves it's never a has to :-)