When you take a taxi or buy a burger, do you think the people you're receiving the service from are doing it because they like it? And you might say sex is more degrading than driving a taxi or making fries, there are plenty of jobs that are both more degrading and more dangerous.
If you feel mining, garbage removal, and cleaning services are too cruel to the worker, do you respond by not using electronics or tools with mined materials, taking your trash to the dump yourself, and cleaning your office yourself without allowing a company to do it?
I think your heart is in the right place, but there is a bigger picture you're missing. There is one group that clearly sees the big picture: former prostitutes. Why don't we listen to them? I've only heard one or two interviews with former prostitutes (now advocates), and they don't want people to stop visiting prostitutes. They want deregulation. (Note: deregulation isn't the same as legalization, because legalization lets the government set cumbersome rules, which has potential to create a new black market, centralized brothels which could be unsafe, or an under-class of former hookers that can't get ever decent jobs because their name got on a government list and leaked.)
And servers are another case. Server applications would definitely need to be rewritten, but until then they can continue running with legacy (user-based) permissions. User-based permissions work better on a server than on a desktop. (On desktop, the user-based permission model is destined to fail, since every application is launched by one user.)
It's not completely unworkable, it's just in very early stages. And most desktop application don't need to be rewritten. Web browser: needs a rewrite so its permissions are integrated with file pickers (giving an implicitly granted permission) and prompted permissions. File explorer: needs a minor change to de-escalate permission of launched apps. Terminal: no change (running with permissive permissions, like before selinux). Chat applications: optional change (running with permission to write only to their config/data directories and read/etc and the camera/mic and their install path, but file attachments won't work until it adds implicit permission-granting via the file picker widget). Bittorrent app can run with legacy permissions until it's rewritten to use implicit permissions granted by file-picker. Git tools need to run in legacy mode. Game engines and 3D games could have restrictive permissions with no rewrite, or they could run in legacy mode for highest performance.
You're being pessimistic. Most applications could run in legacy mode until they support finer grained permissions, and many other apps could run with restricted permissions and not even know they're being restricted.
That stuff is all interface, not core to the execution of a Linux application. Dependencies aren't an issue because permissions are based on the process or user, not the file. (This is still an issue when a daemon is a dependency, or when a file has effective permissions of another user/group, but those are separate cases.) I don't have a complete solution, but modifying/etc (aside from/etc/$APP_NAME) could be considered a master-level permission, and the package manager would run with rights that don't allow that change unless the user approved the master-level permission for the application being installed. (Note that installation permissions wouldn't be the same as runtime permissions. Neither permission set should allow excessive read/write access.)
Compilers and interpreters aren't hard, either. They're just normal executables. If a rogue application launches "bash -c 'rm -rf/'", it should fail if the parent application doesn't have permission to touch files in/.
Do you have any other examples of why this isn't possible in principle?
Drop this selinux shit. It's too complicated and causes more problems than it solves. Vulnerabilities come from bad code, not a lack of complex call ACLs. Security is a process, not a feature.
It would be really nice to be able to run software without worrying about the amount of damage it could do. Android apps are fairly limited in what they can do, and in the absence of a root exploit, they can't go beyond their stated permissions, and can do nothing whatsoever after they've been uninstalled. I assume we're a long way off from having the right permission granularity and the good UIs for managing them, but this is a model we should at least explore further.
We may have different metrics. I chose a language that's highly effective and widely used. Its design obviously isn't bad enough to keep people from using it. I didn't cherry-pick it, either. I could have named Haskell as an example of difficulty and theoretical simplicity hampered by conceptual complexity. I have other complaints about Python, Ruby, and Java, so I wouldn't use them as examples in language comparisons. C# is nice but not syntactically expressive and with a weak class/inheritance model. C++ is a damn useful language, despite its warts.
it's too complex when other languages can do the same job with a fifth or less the syntax, Larry and co. went crazy and threw in everything and the kitchen sink
I have sympathy for that viewpoint, but it's no more complex than C++ (including the two most common libraries), but it does a lot more with less library use and boilerplate. It took me a month to feel comfortable with Perl 6. A lot of that "kitchen sink" stuff is really useful. gather/take iteratively builds data structures. emit/tap is for event handling. Junctions and parallel loops are just plain awesome. But each feature seemed unnecessary until I needed to use it. I'd advise against making a firm judgment without using Perl 6 on a project, or at least analyzing how its features would be used on a project. (I still use the old perl for little scripts, especially those that need to be dead reliable.)
It has potential. Perl 6 is full of good ideas, so I started using it for a small project. Don't think of it as perl--it is something new, and it hasn't gained big popularity yet. It's not a new version, it's a new language. If they'd called it P++ instead of Perl 6, it would have been a more accurate description.
Can you restrict foreground data? I can on my phone, but I'm not sure whether that's a core Android feature. Moreover, manufacturers may re-skin the OS to hide features like that. This tool may be a way to get around manufacturers that don't care about customer choices.
Personally, I just avoid phones with defective UIs--Samsung, Huawei, I'm looking at you!
Yeah, I agree that nothing she did was that bad, unless she was complicit in rigging primaries/caucuses, and I'm too far removed from the scene (literally and figuratively) to know anything except how it looked.
Clinton didn't lose because of bad things she did. That's obvious.
Like I said, it's a double whammy of the relatively minor bad stuff she's done (and the stories about her which seem to be by and large untrue), and the fact that people don't like her. Trump is a despicable human being, but damn does he have charisma. Well, I didn't watch his speeches, but from based on articles about his campaign, he's in touch with his audience like a professional comedian or storyteller. He was so in touch with the emotion of his audience that he talked shit, not even paying attention to the truth or falsity of his words. It's as if he started a state of collective flow and had no focus left to think about wtf he was actually saying. But why that was enough to make him win--or why Clinton's shortcomings were enough to make her lose--is an analysis I can't make. But it is an absolute certainty that there was more at play than her sex.
Those aren't very interesting criticisms, since you picked the ones that weren't true. Here are some that are more interesting: She charged an extremely high speaking fee at a charity dinner (IIRC it was around half of what the event brought in) instead of making a donation herself. She made contradictory campaign promises to different groups of people. She's unlikeable--and please don't attribute that to her being a woman. Nobody says that about the majority of female politicians. She entered politics by marriage instead of by election. She got special privileges from the DNC which were designed to prevent her opponents from having a fair chance.
Sure, she was qualified for the job. She would have made a decent president. But she didn't play by the rules, and didn't really show any significant redeeming qualities (as a person) which would have let people look past her shortcomings.
If you want to get this fixed, I can give some tips. First, note that the same bug is present in "git diff", so it's not just a gitk thing. Next, you can use "git blame" or "git log -p" to find the commit that originally added that bug. (Find the commit that touched those lines--who added this broken feature?) If you can't understand it, e-mail the original author or the git mailing list. If it seems like a useless feature, ask if it can be removed, and mention that it's buggy. If they say yes, submit a patch that deletes it in a more thorough way than just adding "if (0 &&..."
If the feature can't be removed, either it's a fundamental conflict (some protocol adds "" to the file and it can't be changed), or it's fixable. If you can, make some change to the feature so it can be implemented without trying to match "". If it's not fixable, perhaps it could be changed to an option. In that case, this check (which breaks --word-diff=color) won't be done unless the user has requested it.
Gitolite is one piece of software that lets you "set and forget" a git server that seldom needs maintenance. The only time I've run into problems with it is when the server ran out of memory during a large operation. But that could be prevented by enabling swap.
Does not your constitution say that each should be treated equally before the law and that one should not be discriminated against based on their religion? Or does that only apply in circumstances that the ruling clique determine?
It applies only to citizens. And vetting for immigration isn't a matter of law, anyhow.
Haskell and Python share the trait that one-liners are very hard to write. (Specifically, it's very hard to cram code into a shorter space for the purpose of copy/pasting or sharing it in a format intended to be copied/pasted.) This is something I despise about python. It's less restrictive in Haskell. I like to play with the REPL and test a lot of things very rapidly. If I can't define a full idea in one line, it plays havoc with command history, and forces me to use up half the screen to type a relatively small set of ideas.
So if the limited and restrictive syntax is the least shitty thing about Python, I tremble to think about the really shitty parts. (Global Interpreter Lock? Not much of a problem for toy scripting, but you wouldn't want to write a real application in Python. Lack of any static checking? This one means you can never upgrade your libraries without testing each API call.)
I have almost exactly the same computer (MSI GL62) and I strongly do not recommend if you care a lot about input. They screwed up the touchpad positioning so it's constantly pressed during normal typing. And if you configure the driver to be less sensitive, normal touches stop working. For example, a tap after cursor movement isn't accepted, and taps are all ignored when using the touchpad and arrow keys at the same time. (So much for a gaming laptop!)
Granted, I've only compared this laptop to brands that are known for having good input controls (Thinkpads and Macbooks), but the way MSI keyboards and touchpads work together is quite bad. I've been tempted to just put masking tape over the upper corners of the touchpad, but I don't want to deal with sticky residue it would leave if it ever gets warm.
The smaller the laptop, the tighter the key spacing. If you want tight keys, you need to look at a small screen.
Maybe, but I would look for laptops with a numpad and tab/capslock/enter/backspace keys. That will necessarily mean the center keys aren't too widely spaced.
He can buy his own windows box with the money he makes working at his after-school job.
I don't have kids, but that seems inefficient, given that an adult earns several times more and has 4x more time available for working. That's like a marriage between a millionaire and an average joe where the millionaire demands the other guy contribute 50/50 to vacations.
Like a parent (usually) brings a kid along for vacations, some reasonable amount of entertainment is something a parent should also pay for. Perhaps offering a cheap laptop, or just giving the money to be put toward a better laptop? Or offering to match the kid's monetary contribution, up to the price of a computer that doesn't totally suck, which incidentally is the same price for Linux or Windows.
Point of fact: for a simple pool of worker threads with a single work queue and a single result queue, the threading model is perfect.
Even that model falls down very quickly for non-trivial cases. For example, last I checked user a LWP::UserAgent across threads was a fail...
I understand why it's such a mess; threading was something added as a bag on the side rather than having the interpreter designed around it. I'd just have preferred to see Perl 6 as a compatible refactoring rather than as a new-ish language.
You mean creating one UserAgent per thread doesn't cut it? Because that seems like par for the course.
As for why threading is a mess, it's not only because it was bolted on. I suspect it's also because Perl team didn't take one big shortcut that Ruby and Python did: Perl doesn't use a global interpreter lock to prevent more than one thread from accessing just about any functions/data at the same time as another thread. I was amazed when I found out that in Python, four threads doing computations won't accomplish any more than a single thread. This seems like cheating: they aren't threads at all. No more useful than coroutines. Perhaps not taking that shortcut slowed Perl's progress. (I don't think Java or.NET have pathetic global locking either, but huge time and money went into their development. Haskell doesn't have a global interpreter lock, but Haskell was created by the type of people that do quantum physics for fun.)
It is so much more than that. The type system is extremely powerful and useful for implicit error checking. For example, I just defined a "Team" type to be a nonempty list of integers where each integer is a valid team member. So any time the application gets array data from the network that's supposed to describe a team, it's automatically error checked without needing to be deserialized to a custom class (or god forbid, calling "assert(is-team(team))" each time). I wrote the rule that the array must conform to, so creating/changing it in a way that it no longer follows the rule is an error.
The same power goes into parameter parsing for function overloading. You're not limited to overloading based on classes and number of arguments. You can overload based on the characteristics/values of the arguments, so a recursive base case could be called based on a trait of the argument. It should cut down on errors, because you know you'll never forget the check that calls the base case since it's automatic once defined as a function overload.
Perl 6 is a very big language, and I haven't mentioned things like its parsing library, which might be its killer feature if you need to write parsers.
Slashdot Mirror
When you take a taxi or buy a burger, do you think the people you're receiving the service from are doing it because they like it? And you might say sex is more degrading than driving a taxi or making fries, there are plenty of jobs that are both more degrading and more dangerous.
If you feel mining, garbage removal, and cleaning services are too cruel to the worker, do you respond by not using electronics or tools with mined materials, taking your trash to the dump yourself, and cleaning your office yourself without allowing a company to do it?
I think your heart is in the right place, but there is a bigger picture you're missing. There is one group that clearly sees the big picture: former prostitutes. Why don't we listen to them? I've only heard one or two interviews with former prostitutes (now advocates), and they don't want people to stop visiting prostitutes. They want deregulation. (Note: deregulation isn't the same as legalization, because legalization lets the government set cumbersome rules, which has potential to create a new black market, centralized brothels which could be unsafe, or an under-class of former hookers that can't get ever decent jobs because their name got on a government list and leaked.)
Read up on generators and how demand influences frequency.
Are you talking about local load control? That doesn't sound like the cause, but it would have the same effect.
Are you actually retarded? Do I really have to explain to you why plastic or rubber jewelry isn't practical?
Not all plastics are like the junk CD cases are made out of. You can get sufficiently durable/inert plastic. Lack of heft is the big problem I see.
And servers are another case. Server applications would definitely need to be rewritten, but until then they can continue running with legacy (user-based) permissions. User-based permissions work better on a server than on a desktop. (On desktop, the user-based permission model is destined to fail, since every application is launched by one user.)
It's not completely unworkable, it's just in very early stages. And most desktop application don't need to be rewritten. Web browser: needs a rewrite so its permissions are integrated with file pickers (giving an implicitly granted permission) and prompted permissions. File explorer: needs a minor change to de-escalate permission of launched apps. Terminal: no change (running with permissive permissions, like before selinux). Chat applications: optional change (running with permission to write only to their config/data directories and read /etc and the camera/mic and their install path, but file attachments won't work until it adds implicit permission-granting via the file picker widget). Bittorrent app can run with legacy permissions until it's rewritten to use implicit permissions granted by file-picker. Git tools need to run in legacy mode. Game engines and 3D games could have restrictive permissions with no rewrite, or they could run in legacy mode for highest performance.
You're being pessimistic. Most applications could run in legacy mode until they support finer grained permissions, and many other apps could run with restricted permissions and not even know they're being restricted.
That stuff is all interface, not core to the execution of a Linux application. Dependencies aren't an issue because permissions are based on the process or user, not the file. (This is still an issue when a daemon is a dependency, or when a file has effective permissions of another user/group, but those are separate cases.) I don't have a complete solution, but modifying /etc (aside from /etc/$APP_NAME) could be considered a master-level permission, and the package manager would run with rights that don't allow that change unless the user approved the master-level permission for the application being installed. (Note that installation permissions wouldn't be the same as runtime permissions. Neither permission set should allow excessive read/write access.)
Compilers and interpreters aren't hard, either. They're just normal executables. If a rogue application launches "bash -c 'rm -rf /'", it should fail if the parent application doesn't have permission to touch files in /.
Do you have any other examples of why this isn't possible in principle?
Drop this selinux shit. It's too complicated and causes more problems than it solves. Vulnerabilities come from bad code, not a lack of complex call ACLs. Security is a process, not a feature.
It would be really nice to be able to run software without worrying about the amount of damage it could do. Android apps are fairly limited in what they can do, and in the absence of a root exploit, they can't go beyond their stated permissions, and can do nothing whatsoever after they've been uninstalled. I assume we're a long way off from having the right permission granularity and the good UIs for managing them, but this is a model we should at least explore further.
We may have different metrics. I chose a language that's highly effective and widely used. Its design obviously isn't bad enough to keep people from using it. I didn't cherry-pick it, either. I could have named Haskell as an example of difficulty and theoretical simplicity hampered by conceptual complexity. I have other complaints about Python, Ruby, and Java, so I wouldn't use them as examples in language comparisons. C# is nice but not syntactically expressive and with a weak class/inheritance model. C++ is a damn useful language, despite its warts.
it's too complex when other languages can do the same job with a fifth or less the syntax, Larry and co. went crazy and threw in everything and the kitchen sink
I have sympathy for that viewpoint, but it's no more complex than C++ (including the two most common libraries), but it does a lot more with less library use and boilerplate. It took me a month to feel comfortable with Perl 6. A lot of that "kitchen sink" stuff is really useful. gather/take iteratively builds data structures. emit/tap is for event handling. Junctions and parallel loops are just plain awesome. But each feature seemed unnecessary until I needed to use it. I'd advise against making a firm judgment without using Perl 6 on a project, or at least analyzing how its features would be used on a project. (I still use the old perl for little scripts, especially those that need to be dead reliable.)
It has potential. Perl 6 is full of good ideas, so I started using it for a small project. Don't think of it as perl--it is something new, and it hasn't gained big popularity yet. It's not a new version, it's a new language. If they'd called it P++ instead of Perl 6, it would have been a more accurate description.
Can you restrict foreground data? I can on my phone, but I'm not sure whether that's a core Android feature. Moreover, manufacturers may re-skin the OS to hide features like that. This tool may be a way to get around manufacturers that don't care about customer choices.
Personally, I just avoid phones with defective UIs--Samsung, Huawei, I'm looking at you!
Yeah, I agree that nothing she did was that bad, unless she was complicit in rigging primaries/caucuses, and I'm too far removed from the scene (literally and figuratively) to know anything except how it looked.
Clinton didn't lose because of bad things she did. That's obvious.
Like I said, it's a double whammy of the relatively minor bad stuff she's done (and the stories about her which seem to be by and large untrue), and the fact that people don't like her. Trump is a despicable human being, but damn does he have charisma. Well, I didn't watch his speeches, but from based on articles about his campaign, he's in touch with his audience like a professional comedian or storyteller. He was so in touch with the emotion of his audience that he talked shit, not even paying attention to the truth or falsity of his words. It's as if he started a state of collective flow and had no focus left to think about wtf he was actually saying. But why that was enough to make him win--or why Clinton's shortcomings were enough to make her lose--is an analysis I can't make. But it is an absolute certainty that there was more at play than her sex.
Those aren't very interesting criticisms, since you picked the ones that weren't true. Here are some that are more interesting: She charged an extremely high speaking fee at a charity dinner (IIRC it was around half of what the event brought in) instead of making a donation herself. She made contradictory campaign promises to different groups of people. She's unlikeable--and please don't attribute that to her being a woman. Nobody says that about the majority of female politicians. She entered politics by marriage instead of by election. She got special privileges from the DNC which were designed to prevent her opponents from having a fair chance.
Sure, she was qualified for the job. She would have made a decent president. But she didn't play by the rules, and didn't really show any significant redeeming qualities (as a person) which would have let people look past her shortcomings.
Why do you have to ruin an otherwise informative post by bringing up a highly contentious off-topic issue like that?
Not a programmer, are you?
If you want to get this fixed, I can give some tips. First, note that the same bug is present in "git diff", so it's not just a gitk thing. Next, you can use "git blame" or "git log -p" to find the commit that originally added that bug. (Find the commit that touched those lines--who added this broken feature?) If you can't understand it, e-mail the original author or the git mailing list. If it seems like a useless feature, ask if it can be removed, and mention that it's buggy. If they say yes, submit a patch that deletes it in a more thorough way than just adding "if (0 && ..."
If the feature can't be removed, either it's a fundamental conflict (some protocol adds "" to the file and it can't be changed), or it's fixable. If you can, make some change to the feature so it can be implemented without trying to match "". If it's not fixable, perhaps it could be changed to an option. In that case, this check (which breaks --word-diff=color) won't be done unless the user has requested it.
Gitolite is one piece of software that lets you "set and forget" a git server that seldom needs maintenance. The only time I've run into problems with it is when the server ran out of memory during a large operation. But that could be prevented by enabling swap.
To clarify, I'm pointing out constitutional/legal misconceptions, not proposing discrimination.
Does not your constitution say that each should be treated equally before the law and that one should not be discriminated against based on their religion?
Or does that only apply in circumstances that the ruling clique determine?
It applies only to citizens. And vetting for immigration isn't a matter of law, anyhow.
Haskell and Python share the trait that one-liners are very hard to write. (Specifically, it's very hard to cram code into a shorter space for the purpose of copy/pasting or sharing it in a format intended to be copied/pasted.) This is something I despise about python. It's less restrictive in Haskell. I like to play with the REPL and test a lot of things very rapidly. If I can't define a full idea in one line, it plays havoc with command history, and forces me to use up half the screen to type a relatively small set of ideas.
So if the limited and restrictive syntax is the least shitty thing about Python, I tremble to think about the really shitty parts. (Global Interpreter Lock? Not much of a problem for toy scripting, but you wouldn't want to write a real application in Python. Lack of any static checking? This one means you can never upgrade your libraries without testing each API call.)
I have almost exactly the same computer (MSI GL62) and I strongly do not recommend if you care a lot about input. They screwed up the touchpad positioning so it's constantly pressed during normal typing. And if you configure the driver to be less sensitive, normal touches stop working. For example, a tap after cursor movement isn't accepted, and taps are all ignored when using the touchpad and arrow keys at the same time. (So much for a gaming laptop!)
Granted, I've only compared this laptop to brands that are known for having good input controls (Thinkpads and Macbooks), but the way MSI keyboards and touchpads work together is quite bad. I've been tempted to just put masking tape over the upper corners of the touchpad, but I don't want to deal with sticky residue it would leave if it ever gets warm.
The smaller the laptop, the tighter the key spacing. If you want tight keys, you need to look at a small screen.
Maybe, but I would look for laptops with a numpad and tab/capslock/enter/backspace keys. That will necessarily mean the center keys aren't too widely spaced.
He can buy his own windows box with the money he makes working at his after-school job.
I don't have kids, but that seems inefficient, given that an adult earns several times more and has 4x more time available for working. That's like a marriage between a millionaire and an average joe where the millionaire demands the other guy contribute 50/50 to vacations.
Like a parent (usually) brings a kid along for vacations, some reasonable amount of entertainment is something a parent should also pay for. Perhaps offering a cheap laptop, or just giving the money to be put toward a better laptop? Or offering to match the kid's monetary contribution, up to the price of a computer that doesn't totally suck, which incidentally is the same price for Linux or Windows.
Even that model falls down very quickly for non-trivial cases. For example, last I checked user a LWP::UserAgent across threads was a fail...
I understand why it's such a mess; threading was something added as a bag on the side rather than having the interpreter designed around it. I'd just have preferred to see Perl 6 as a compatible refactoring rather than as a new-ish language.
You mean creating one UserAgent per thread doesn't cut it? Because that seems like par for the course.
As for why threading is a mess, it's not only because it was bolted on. I suspect it's also because Perl team didn't take one big shortcut that Ruby and Python did: Perl doesn't use a global interpreter lock to prevent more than one thread from accessing just about any functions/data at the same time as another thread. I was amazed when I found out that in Python, four threads doing computations won't accomplish any more than a single thread. This seems like cheating: they aren't threads at all. No more useful than coroutines. Perhaps not taking that shortcut slowed Perl's progress. (I don't think Java or .NET have pathetic global locking either, but huge time and money went into their development. Haskell doesn't have a global interpreter lock, but Haskell was created by the type of people that do quantum physics for fun.)
It is so much more than that. The type system is extremely powerful and useful for implicit error checking. For example, I just defined a "Team" type to be a nonempty list of integers where each integer is a valid team member. So any time the application gets array data from the network that's supposed to describe a team, it's automatically error checked without needing to be deserialized to a custom class (or god forbid, calling "assert(is-team(team))" each time). I wrote the rule that the array must conform to, so creating/changing it in a way that it no longer follows the rule is an error.
The same power goes into parameter parsing for function overloading. You're not limited to overloading based on classes and number of arguments. You can overload based on the characteristics/values of the arguments, so a recursive base case could be called based on a trait of the argument. It should cut down on errors, because you know you'll never forget the check that calls the base case since it's automatic once defined as a function overload.
Perl 6 is a very big language, and I haven't mentioned things like its parsing library, which might be its killer feature if you need to write parsers.