171–180 of 280 posts
A while ago I made a small program to cache Steam's grid images and search missing ones ( https://github.com/boppreh/steamgrid ). More of an experiment in programming in Go, really, but it works and makes Steam a little better. When I tried on Linux, it threw a permission error. Turns out Steam installs the folder "~/.local/share/Steam/userdata/[userid]/config/grid" without the executable permission bit. Without this…
Earlier quoted context omitted.
Sandboxed applications in OS X can read/write to arbitrary locations if they use the system Open/Save dialogs to ask the user about those files (after opting into sandboxing, of course). See here [1]. For files and folders the user cares and knows about (documents, projects, etc), this shouldn't be a problem. For files the user doesn't care about (caches, configuration), you can just leave them in your sandboxed cont…
Lots of applications (like Emacs and vim) don't use the system file dialogs though. It'd be nice to preserve old-fashioned file access for them.
Earlier quoted context omitted.
Lots of applications (like Emacs and vim) don't use the system file dialogs though. It'd be nice to preserve old-fashioned file access for them.
Aquamacs seems to use the system dialogs with no trouble.
Earlier quoted context omitted.
There are several problems with your ideas. The most important one is that programmers only call themselves engineers until it comes time to take legal responsibility for their work; then suddenly they're artists creating works for hire. Programmers have worked very hard through the years to create the current liability-free environment; people die because of health care programming bugs, pilots crash because of avio…
I don't know. I think the main problem with the parent idea is '...and lose'. Perhaps they should be sued (presumably as a class-action), but whether or not they lose is TBD. The parent wants them to be sued only so that they necessarily lose .
Earlier quoted context omitted.
Would this have stopped things getting deleted? if [ -z "$STEAMROOT" ] # something isnt right...
Not if the previous line was: STEAMROOT=$SOME_OTHER_UNSET_VARIABLE/ "rm -r " is a code smell, as much as "cc -o myprog .c" is. You should always know what files make up your system, and track them in a MANIFEST file. There's rarely a good reason to use wildcards when a program is dealing with its own files. xargs rm -df -- fixes this.
For GNU xargs I like adding -d\\n which handles everything except files with an embedded newline. Those are much rarer than files with a space, though.
Sadly, OS X xargs (probably BSD based) doesn't have that option, so I have an alias to do the same thing:
alias xargsn="tr '\n' '\0' | xargs -0"Earlier quoted context omitted.
If a problem has been solved several times over, that's a sign that it has never really been solved. If there's a thing that most apps should do, then doing it should be the default, and avoiding the default should be the thing that takes work.
So what, your definition of a solved problem is one that never occurs again due to uniform implementation of countermeasures? That isn't realistic. That is like saying that plane geometry isn't a solved problem because people are still walking around having not read Euclid's "Elements", doing geometry wrong.
Earlier quoted context omitted.
How about using a better language? She'll scripting is an awful, awful language. An error like this wouldn't have happened if the program had been written in C or Python or Perl or whatever your choice might be. Shell scripting seems tremendously overused. It makes some things a bit easier, but it's so crazy it makes PHP a look like a pinnacle of good language design.
Using C or Python or Perl does not automatically keep people from failing to check whether some code that reaches out into the environment to prepare for later action actually succeeded.
Earlier quoted context omitted.
So what, your definition of a solved problem is one that never occurs again due to uniform implementation of countermeasures? That isn't realistic. That is like saying that plane geometry isn't a solved problem because people are still walking around having not read Euclid's "Elements", doing geometry wrong.
Just because you've invented solar panels does not mean that you've solved the energy crisis. Sometimes the implementation of technology is just as inventive as the invention itself.
Converting sunlight to electricity is a solved problem. The "energy crisis" remains unsolved.
Jailing processes is a solved problem. Preventing users from shooting themselves in the foot remains unsolved.
Now let us reexamine the post:
> ...would be a helpful thing to build into modern operating systems...
Already built in.
> Why can’t we also have something analogous where different files or other system resources are only accessible to applications that have been approved for that access?
We do. Solved problem. Now if we want to prevent users from shooting themselves, that is a different problem.
That last paragraph sure makes it sound like the writer is unaware of these solution's existence... but let us suppose that he knows about them and is coming at it from your perspective. In that case I agree, we don't have a solution in place - and I'd love to see one in common use. I'd think you'd be able to implement such a system through package management for the majority of software, an added chroot step. That is why I included distro and application devs in those that share blame for the problem. Users are also included, to a smaller degree, because this is a known problem with a known solution.
This is a danger of me-ware being used before it becomes software. Software assumes and defends against others using and running it. Me-ware makes no assumptions because me is the only one running it. The transition from meware to software is a hard one - and usually it's how we get terrible reputations as an industry. Basically it's a prototype till it's burned enough beta users. Edit OMG - that is actually Steam fr…