For instance, by your argument there's no such thing as an electrical generator at all. For example, those big things in a hydro dam? They don't generate electricity, they merely convert energy.
This is like saying a car is bad because the gas hose does not fit when it gets cold.
Yes, if the company that designed and manufactured your car also designed and manufactured the gas hose in a way that was specifically engineered to work with your car. Then it would be like that.
The BSD licence provides building blocks for non-free projects that compete against free software. The GPL provides building blocks only for free software projects.
That's only true if you define "free" to be "GPL-compatible." The GPL provides building blocks only for GPL software products. Software licensed under the CDDL is also free software, but GPL doesn't provide you building blocks for combining with that.
The author, Gregory Szorc, seems confused about what "support" means. What he appears to be complaining about is "Why do projects continue to require old Python releases?" (e.g. he says "I successfully transitioned Firefox's build system from requiring Python 2.5+ to 2.7.3+)
Now I'm confused, because you seem to be saying the opposite of what I think you're saying.
The projects don't require older releases, as you say: you can run Python 2.5 stuff on Py2.7. He's asking why people are resistant to requiring a later verison, aka why people continue to allow the older versions to work.
Take the Firefox example. You say "It's the maintainers of those projects who do the work, not him." But... from what I can tell, he is a maintainer of the FF build system. So he does care -- he wants to be able to use the newer features of 2.7!
And then he's wondering why other projects disagree with his approach.
A flight on autopilot has two college educated humans sitting next to the control system. Both being paid six figure salaries and having over 500 hours of training.
Hah. Not on planes run by your typical regional airlines, where you'd be lucky to make 1/3 of a six-figure salary.
I still say that it has to do with what level you want to think of it. If you look at the mechanism by which a policy is achieved, yes, a capability-based system is quite different from the typical Unix model.
But in both cases, you have a program that's saying "if I get told to do something I shouldn't (e.g. by being compromised), I want to make sure I can't do something -- I know, I'll stop my future self from doing it by removing the ability." In the traditional Unix model you do that by changing users, in a more modern *nix you do it by telling the OS to remove not-really-capability privileges, and a Capsicum program would do it by telling the OS to release the actual capabilities it has*. All three are trying to accomplish the same goal, just via different means (and with different amounts of success).
(And since others have mentioned SELinux, SELinux is like someone else saying "hey buster, I'm not going to let you do this thing that you're not supposed to be able to do." Dropping privileges is self-policing your behavior because you trust yourself to try to be good but don't trust yourself to be perfect. SELinux is policing others because you don't trust one or the other. This analogy isn't perfect, but they are pretty different.)
I think both explanations add to the discussion.
* Under Capsicum you can also "drop privileges" by switching into Capsicum mode, as you mention.
Well, it's still dropping features in Capsicum, at least AFAIK. (I have a friend who's doing his PhD dissertation on something related to Capsicum-like systems.)
Capsicum just allows you to drop the ability to drop operations at a finer granularity than would otherwise be possible.
This is supposedly about health *insurance*. Insurance is for contingent, unlikely, but potentially costly events. Contraception is none of those, being completely knowable, 100% predictable, and inexpensive.
Health insurance is weird and not traditional insurance in that sense. Health insurance also covers things like routine medical checkups and dental cleanings with little or no out-of-pocket cost to you, even though those too are completely knowable, predictable, and inexpensive. But of course you realize that.
In the olden days, by which I mean pre-Obamacare, you could indeed "pick and choose" what procedures and medications your policy would cover.
Not realistically for most people. In the real world, your employer would be able to pick and choose what you got, and and if you wanted something else you'd have to go pay an arm and a leg on your own.
Counterargument: I don't know much about audio analysis, but imagine you have two people talking with different-pitched voices. I wouldn't be at all surprised if a computer, via some FFT and frequency analysis or something, would be able to do a far better job at separating them than a person could. Actually, I'd be a bit surprised if that wasn't true.
Things become more difficult of course with similar-sounding voices, but I still suspect there's a fair bit of potential. There have been a lot of things people have done along this line.
(OK, one more comment. "Aug 13" and "May 13" can be done. But what about "Aug 13 2012", "May 13, 2011", and "Sep 13, 2013"? You can do it with multiple iterations of sort, but now you're really turning the task into a PITA.)
(I guess I should say: or the information is there at least to coarsely sort, but not in a format that sort can deal with. Take the output of ls -l; recent files are shown with something like "Dec 3 08:15", while older ones are shown with something like "Sep 13 2012". Show me the sort flag that will put those in the proper order. Hell, show me the sort flag that will put "Aug 13" and "May 13" in the proper order.)
You said "ls has only sort flags because you might sort on internal values (say, timestamps), which are made human-readable before output" [emphasis mine].
Why does ls need to know how to sort? Because the output isn't sortable. It doesn't matter that sort can sort by column, because the information isn't there.
I'm not surprised, and thanks for the link. (Although god is it hard to read.) It's really interesting how old it is. I also have some things I'd really like to see the terminal emulator do (I think restricting ourselves to an N x M block of monospaced characters doesn't make sense any more and we can do a lot better) that are in sort of the same spirit as what he suggests, and there are a number of neat projects along that line as well, but all of the other projects that I know of are recent in comparison.
I also disagree with XML as the interchange format; I think it's too heavyweight, and I think it's still important that the output be consumable by other tools and still be somewhat more human-readable than XML is, even if it's not as ideal raw as current command output is. Like I said, I think JSON strikes a better balance, as much as there are a couple things I don't like about it and as superficially resistant to it from a buzzword standpoint.:-)
that being said, sort can sort on arbitrary colums (-k) Your point is moot.
It's amazing how you basically agreed with half of my exact point -- that utilities have internal representations that they have to force into a human-readable format even when that makes consumption by downstream utilities problematic or impossible -- and still say that I'm wrong.
They have added a new option "-i" which asks for confirmation before deleting the file, of course that doesn't actually solve the mis-type problem.
You should be able to alias crontab="crontab -i" and it will at least solve it for you. (Or something like that. I didn't test it and use crontab once in a blue moon.)
If you don't understand why text is a very sensible lingua franca, I'd suggest that perhaps you shouldn't be writing parsers.
Text has a lot of positives, but it also has a lot of drawbacks. Very frequently, I want to carry out tasks that are made somewhere between 'somewhat annoying' and 'completely impossible' because of it. In some sense, what's the core principle of the Unix command line? At least according to me, it's "have lots of composible programs, each of which does exactly one thing well." Except Unix doesn't have that. ls has sorting flags despite the presence of sort. Why? Because the textual output of ls is at best poorly-suited and at worst impossible to sort by piping it to sort. So instead of having ls be good at one thing -- listing files -- and composing it with sort, you have to learn a different set of flags. And then ps comes along, and the people writing it and using it have to implement and learn yet another set of flags, because it can't be composed with sort. This sort of problems crops up all over the place, and while I'm mostly a Linux dev and so haven't really played around with Powershell, it's something I think that Powershell would be able to do way better. If Unix utilities were set up to pass around structured data instead of the same text meant for human consumption, the entire toolset becomes more Unixy, not yes. At least that's my hypothesis. (This doesn't necessarily mean you have to go as far as Powershell does in terms of passing around true objects with behavior, but I would loooove a set of Unix replacement utils that passed around, say, JSON. Actually I'm theoretically writing a set, but I haven't worked on it for a year or so.:-))
I actually have a whole rant about this I can link later if anyone is interested.
Now, with SVN blowing up in everyone's face, and with Github becoming a de facto standard, many are turning to git. And git, while it has a few interesting UIs, simply blows on Windows. I got it to work the way I liked, but it took a lot of Powershell black magic and reverse engineering some of the Unix tools...
What? Not only have I not had command-line Git problems on Windows, but TortoiseGit (in my experience, anyway) works better than TortiseSVN does!
Give them a spindle of CDs and tell them that you want a complete rips in mp3, FLAC, AAC, and in multiple bitrates with appropriate tags from CDDB.
Incidentally, I can do all of that from a GUI as efficiently as you could from the command line -- and get more-assuredly-correct results (if you care about ripping accuracy). The limiting factor of that task -- and trust me, I've done it -- is waiting for the rips to complete and changing CDs out. Transcoding, with the right software, is as simple as right clicking the folder you ripped to, saying "convert to", then choosing the format from the pull-down list. If you gave more than 2 or 3 bit rates per format I might look at command-line options for the transcoding, but not with fewer.
As I've said elsewhere in this thread, I do 95% of my work work via SSH into a Linux box, so I'm pretty-well versed in its strengths and weaknesses. And... IMO, you choose a very weird task if you intend to illustrate its strengths.
I don't find most of your examples very convincing, and this is coming from someone who does 95% of his work via SSH into a Linux box.
Write a short simple program to demonstrate some API? Fast in IDEs as well. (Well, with a caveat: I have a dedicated "cppscratch" project in Visual Studio that I open for throwaway tasks like that. If you actually have to go through and create a new project, that's another 30 seconds, and I'll agree that the IDE is getting a bit heavyweight there.)
Type in PowerPoint slides? Escape, fix, F5 -- probably takes less time than just the recompile, especially when using Beamer.
The manpages are somewhat more convincing, but on Windows you get help COMMAND.
Slashdot Mirror
You're nitpicking.
For instance, by your argument there's no such thing as an electrical generator at all. For example, those big things in a hydro dam? They don't generate electricity, they merely convert energy.
Yes, if the company that designed and manufactured your car also designed and manufactured the gas hose in a way that was specifically engineered to work with your car. Then it would be like that.
Unless those design limits we set without regard to reality.
Because you're dumb and don't know to plan ahead with your gas purchases, while the Tesla is a design or build problem with the car (charger)?
That's only true if you define "free" to be "GPL-compatible." The GPL provides building blocks only for GPL software products. Software licensed under the CDDL is also free software, but GPL doesn't provide you building blocks for combining with that.
Because it didn't "work fine." They were doing things like debugging then working around Python bugs that are fixed in later versions.
Now I'm confused, because you seem to be saying the opposite of what I think you're saying.
The projects don't require older releases, as you say: you can run Python 2.5 stuff on Py2.7. He's asking why people are resistant to requiring a later verison, aka why people continue to allow the older versions to work.
Take the Firefox example. You say "It's the maintainers of those projects who do the work, not him." But... from what I can tell, he is a maintainer of the FF build system. So he does care -- he wants to be able to use the newer features of 2.7!
And then he's wondering why other projects disagree with his approach.
A flight on autopilot has two college educated humans sitting next to the control system. Both being paid six figure salaries and having over 500 hours of training.
Hah. Not on planes run by your typical regional airlines, where you'd be lucky to make 1/3 of a six-figure salary.
I still say that it has to do with what level you want to think of it. If you look at the mechanism by which a policy is achieved, yes, a capability-based system is quite different from the typical Unix model.
But in both cases, you have a program that's saying "if I get told to do something I shouldn't (e.g. by being compromised), I want to make sure I can't do something -- I know, I'll stop my future self from doing it by removing the ability." In the traditional Unix model you do that by changing users, in a more modern *nix you do it by telling the OS to remove not-really-capability privileges, and a Capsicum program would do it by telling the OS to release the actual capabilities it has*. All three are trying to accomplish the same goal, just via different means (and with different amounts of success).
(And since others have mentioned SELinux, SELinux is like someone else saying "hey buster, I'm not going to let you do this thing that you're not supposed to be able to do." Dropping privileges is self-policing your behavior because you trust yourself to try to be good but don't trust yourself to be perfect. SELinux is policing others because you don't trust one or the other. This analogy isn't perfect, but they are pretty different.)
I think both explanations add to the discussion.
* Under Capsicum you can also "drop privileges" by switching into Capsicum mode, as you mention.
That's actually a really neat idea.
Well, it's still dropping features in Capsicum, at least AFAIK. (I have a friend who's doing his PhD dissertation on something related to Capsicum-like systems.)
Capsicum just allows you to drop the ability to drop operations at a finer granularity than would otherwise be possible.
Health insurance is weird and not traditional insurance in that sense. Health insurance also covers things like routine medical checkups and dental cleanings with little or no out-of-pocket cost to you, even though those too are completely knowable, predictable, and inexpensive. But of course you realize that.
Not realistically for most people. In the real world, your employer would be able to pick and choose what you got, and and if you wanted something else you'd have to go pay an arm and a leg on your own.
Counterargument: I don't know much about audio analysis, but imagine you have two people talking with different-pitched voices. I wouldn't be at all surprised if a computer, via some FFT and frequency analysis or something, would be able to do a far better job at separating them than a person could. Actually, I'd be a bit surprised if that wasn't true.
Things become more difficult of course with similar-sounding voices, but I still suspect there's a fair bit of potential. There have been a lot of things people have done along this line.
(OK, one more comment. "Aug 13" and "May 13" can be done. But what about "Aug 13 2012", "May 13, 2011", and "Sep 13, 2013"? You can do it with multiple iterations of sort, but now you're really turning the task into a PITA.)
(I guess I should say: or the information is there at least to coarsely sort, but not in a format that sort can deal with. Take the output of ls -l; recent files are shown with something like "Dec 3 08:15", while older ones are shown with something like "Sep 13 2012". Show me the sort flag that will put those in the proper order. Hell, show me the sort flag that will put "Aug 13" and "May 13" in the proper order.)
You said "ls has only sort flags because you might sort on internal values (say, timestamps), which are made human-readable before output" [emphasis mine].
Why does ls need to know how to sort? Because the output isn't sortable. It doesn't matter that sort can sort by column, because the information isn't there.
XML is definitely more buzzword-compliant, but that doesn't mean JSON doesn't have a smaller case of the same problem. :-)
But I couldn't think of any other serialized format that seems better on balance.
I'm not surprised, and thanks for the link. (Although god is it hard to read.) It's really interesting how old it is. I also have some things I'd really like to see the terminal emulator do (I think restricting ourselves to an N x M block of monospaced characters doesn't make sense any more and we can do a lot better) that are in sort of the same spirit as what he suggests, and there are a number of neat projects along that line as well, but all of the other projects that I know of are recent in comparison.
I also disagree with XML as the interchange format; I think it's too heavyweight, and I think it's still important that the output be consumable by other tools and still be somewhat more human-readable than XML is, even if it's not as ideal raw as current command output is. Like I said, I think JSON strikes a better balance, as much as there are a couple things I don't like about it and as superficially resistant to it from a buzzword standpoint. :-)
that being said, sort can sort on arbitrary colums (-k)
Your point is moot.
It's amazing how you basically agreed with half of my exact point -- that utilities have internal representations that they have to force into a human-readable format even when that makes consumption by downstream utilities problematic or impossible -- and still say that I'm wrong.
They have added a new option "-i" which asks for confirmation before deleting the file, of course that doesn't actually solve the mis-type problem.
You should be able to alias crontab="crontab -i" and it will at least solve it for you. (Or something like that. I didn't test it and use crontab once in a blue moon.)
If you don't understand why text is a very sensible lingua franca, I'd suggest that perhaps you shouldn't be writing parsers.
Text has a lot of positives, but it also has a lot of drawbacks. Very frequently, I want to carry out tasks that are made somewhere between 'somewhat annoying' and 'completely impossible' because of it. In some sense, what's the core principle of the Unix command line? At least according to me, it's "have lots of composible programs, each of which does exactly one thing well." Except Unix doesn't have that. ls has sorting flags despite the presence of sort. Why? Because the textual output of ls is at best poorly-suited and at worst impossible to sort by piping it to sort. So instead of having ls be good at one thing -- listing files -- and composing it with sort, you have to learn a different set of flags. And then ps comes along, and the people writing it and using it have to implement and learn yet another set of flags, because it can't be composed with sort. This sort of problems crops up all over the place, and while I'm mostly a Linux dev and so haven't really played around with Powershell, it's something I think that Powershell would be able to do way better. If Unix utilities were set up to pass around structured data instead of the same text meant for human consumption, the entire toolset becomes more Unixy, not yes. At least that's my hypothesis. (This doesn't necessarily mean you have to go as far as Powershell does in terms of passing around true objects with behavior, but I would loooove a set of Unix replacement utils that passed around, say, JSON. Actually I'm theoretically writing a set, but I haven't worked on it for a year or so. :-))
I actually have a whole rant about this I can link later if anyone is interested.
Now, with SVN blowing up in everyone's face, and with Github becoming a de facto standard, many are turning to git. And git, while it has a few interesting UIs, simply blows on Windows. I got it to work the way I liked, but it took a lot of Powershell black magic and reverse engineering some of the Unix tools...
What? Not only have I not had command-line Git problems on Windows, but TortoiseGit (in my experience, anyway) works better than TortiseSVN does!
Give them a spindle of CDs and tell them that you want a complete rips in mp3, FLAC, AAC, and in multiple bitrates with appropriate tags from CDDB.
Incidentally, I can do all of that from a GUI as efficiently as you could from the command line -- and get more-assuredly-correct results (if you care about ripping accuracy). The limiting factor of that task -- and trust me, I've done it -- is waiting for the rips to complete and changing CDs out. Transcoding, with the right software, is as simple as right clicking the folder you ripped to, saying "convert to", then choosing the format from the pull-down list. If you gave more than 2 or 3 bit rates per format I might look at command-line options for the transcoding, but not with fewer.
As I've said elsewhere in this thread, I do 95% of my work work via SSH into a Linux box, so I'm pretty-well versed in its strengths and weaknesses. And... IMO, you choose a very weird task if you intend to illustrate its strengths.
I use Spotify while I work, even though I'm not working on Spotify per se.
Actually I put in a fair bit of effort into trying to get it to run on my machine when I was a grad student before giving up.
I don't find most of your examples very convincing, and this is coming from someone who does 95% of his work via SSH into a Linux box.
Write a short simple program to demonstrate some API? Fast in IDEs as well. (Well, with a caveat: I have a dedicated "cppscratch" project in Visual Studio that I open for throwaway tasks like that. If you actually have to go through and create a new project, that's another 30 seconds, and I'll agree that the IDE is getting a bit heavyweight there.)
Type in PowerPoint slides? Escape, fix, F5 -- probably takes less time than just the recompile, especially when using Beamer.
The manpages are somewhat more convincing, but on Windows you get help COMMAND.