That seems like a solution for a different problem. I want the program I'm using to tell me what's wrong; whether I'm using rm or Konqueror, it would be nice to know why I can't delete a file right then and there.
Posted Jan 20, 2013 0:30 UTC (Sun) by dlang (✭ supporter ✭, #313)
[Link]
that will require modifying every application to know about these linux-only error messages. I just don't see that happening. Some apps will be modified, but unless you get other *nix developers to adopt the same error reporting mechanism (with at least similar error codes) you are not going to get very far with this.
If you were to get all the *BSDs to sign on, that would probably be enough.
log why the permission is denied
Posted Jan 20, 2013 0:50 UTC (Sun) by Cyberax (✭ supporter ✭, #52523)
[Link]
It's a high time to ditch POSIXs idiocies and start evolving a better standard. BSDs can either join or continue using the rapidly obsoleting standard. And the good thing is that it can be done incrementally, an extended error reporting even in a few programs would really help.
log why the permission is denied
Posted Jan 20, 2013 0:54 UTC (Sun) by ebiederm (subscriber, #35028)
[Link]
Evolution is fine but backwards compatibility needs to be retained.
log why the permission is denied
Posted Jan 20, 2013 1:03 UTC (Sun) by dlang (✭ supporter ✭, #313)
[Link]
people who want to ditch POSIX compatibility offend me the same way that Big Media does.
Both groups benefit from being able to use the work that came before them, and both groups want to prevent others from benefiting from the work that they are doing (or are arrogant enough to believe that what they are doing is perfect and there will never be any need to build on what they are doing)
I fully expect people to take offence at this comparison, but after you calm down a bit, think about it and you will hopefully be a bit uncomfortable at how close the comparison matches.
log why the permission is denied
Posted Jan 20, 2013 1:13 UTC (Sun) by dvdeug (subscriber, #10998)
[Link]
Linux doesn't run on VAXes. Furthermore, Linux supports those who break ix86 compatibility with their fancy new chipsets. It neither supports the old standard or enforces the new one.
Nobody is obliged to let history chain them in place; if you think you can do better then POSIX, you have the right to try and it's sad that you'll have to endure abuse to do so. Everyone benefits from the work that came before them; *nix systems have been harvesting features from Windows and Apple for years, and designing systems that don't work on those OSes, with no apology.
log why the permission is denied
Posted Jan 20, 2013 21:51 UTC (Sun) by deater (subscriber, #11746)
[Link]
According to that (if I read it correctly), they have it running on 2.6.18 kernel, at least to the CLI.
log why the permission is denied
Posted Jan 20, 2013 1:21 UTC (Sun) by Cyberax (✭ supporter ✭, #52523)
[Link]
Nobody prevents you from, say, reimplementing cgroups on BSD to make systemd possible. That's the crucial difference.
I'm lurking on a lot of mailing lists and too often I see responses that can be summed up as: "It's not POSIX! Burn the heretic!" Meanwhile, competitors who don't care about POSIX beyond the very basics eat up their marketshare.
log why the permission is denied
Posted Jan 20, 2013 9:33 UTC (Sun) by alankila (subscriber, #47141)
[Link]
There is nobody preventing anything. It's just that if a standard is insufficient to meet a new task, you either evolve that standard, or make a new standard. The alternative equals irrelevance and death, so seems like no-brainer to me.
log why the permission is denied
Posted Jan 20, 2013 1:07 UTC (Sun) by dvdeug (subscriber, #10998)
[Link]
You're running a system largely written in C/C++ on (most likely) x86 systems; programming languages with compatibility back to the early 1970s on chips with compatibility back to the early 1970s. Backwards compatibility is a huge winner and breaking old code so bad that Linux is bound to being backwardly compatible.
log why the permission is denied
Posted Jan 20, 2013 1:09 UTC (Sun) by Cyberax (✭ supporter ✭, #52523)
[Link]
We don't need to be backwards-incompatible. It's fine to have POSIX compat layer and API, but it's a good time to start developing a new API.
log why the permission is denied
Posted Jan 20, 2013 1:14 UTC (Sun) by mpr22 (subscriber, #60784)
[Link]
Don't let us stop you.
log why the permission is denied
Posted Jan 20, 2013 1:21 UTC (Sun) by dvdeug (subscriber, #10998)
[Link]
There's always impedence mismatches. VMS's POSIX always had serious problems because VMS is not Unix. A program that doesn't know about the filesystem versioning can't do the right thing about it. If you start from the POSIX level, you have a hard time introducing features like that in the first place, because nothing will handle them correct.
I believe that file names should be valid strings of Unicode characters. But if you do that, there's going to be edge problems where POSIX programs can't access certain files, can't create certain files for reasons inexplicable to them, or the POSIX filename-native filename mapping is confusing. The question is going to be is it worth it?
log why the permission is denied
Posted Jan 20, 2013 1:23 UTC (Sun) by Cyberax (✭ supporter ✭, #52523)
[Link]
Mac OS X shows that enforcing UTF-8 (and normalizing filenames) is totally fine for all real-world practical purposes.
log why the permission is denied
Posted Jan 20, 2013 1:25 UTC (Sun) by dlang (✭ supporter ✭, #313)
[Link]
the ash-heap of history is littered by companies and organizations that have decided that everyone else was wrong, and they knew better and could design such a great system that everyone else would abandon what they use to jump on board.
You act as if the POSIX (and Single Unix Specification) standard is something handed down from on high that hasn't changed in 20 years.
The last revision to POSIX and SUS took place within the last couple of years, and the next one will take place within the next few years.
These standards work by looking at the things that people are developing, and getting consensus between the different developers as to what they can agree on, They then have those developers go and implement what they are proposing, and it only gets into the standard after there are running implementations.
by definition this means that they encourage new, non-standard, things to be developed and deployed (they can't add something to the standard if it hasn't been deployed yet)
The problem isn't with the idea of enhancing things, it's with the idea that standards don't matter, nobody else matters, only develop for yourself and to #$% with everyone else.
log why the permission is denied
Posted Jan 20, 2013 1:31 UTC (Sun) by dvdeug (subscriber, #10998)
[Link]
The ashheap of history is littered with *nix companies. And Microsoft is still out there. History's statement on the matter tells me that you've got to know when to hold them, know when to fold them, know when to walk away, and know when to run. Neither standards nor standard-free innovation is a guarantee of anything.
90% of companies and organizations fail quickly no matter what they do.
log why the permission is denied
Posted Jan 21, 2013 23:13 UTC (Mon) by cmccabe (guest, #60281)
[Link]
So this kind of rant is offtopic in more ways than one...
log why the permission is denied
Posted Jan 22, 2013 17:51 UTC (Tue) by ssmith32 (subscriber, #72404)
[Link]
And windows has one of my favorite error codes/constant names!
ERROR_SUCCESS, of course :)
-stu
log why the permission is denied
Posted Jan 23, 2013 0:36 UTC (Wed) by marcH (subscriber, #57642)
[Link]
... possibly brought by the same people who gave us the Start->Shut Down menu item.
PS: I thought Windows 7 got rid of the "Start" name but I just found it is still showing as a tooltip.
log why the permission is denied
Posted Jan 24, 2013 11:19 UTC (Thu) by sorokin (subscriber, #88478)
[Link]
No. Since introduction of COM it uses IErrorInfo in addition to HRESULT.
log why the permission is denied
Posted Jan 30, 2013 5:53 UTC (Wed) by cmccabe (guest, #60281)
[Link]
COM is a userspace thing, similar to DBus or CORBA. We are discussing kernel APIs here.
log why the permission is denied
Posted Jan 30, 2013 7:33 UTC (Wed) by Cyberax (✭ supporter ✭, #52523)
[Link]
Not really, COM is also used in kernel. IErrorInfo also supports marshalling across processes.
log why the permission is denied
Posted Jan 20, 2013 1:36 UTC (Sun) by Cyberax (✭ supporter ✭, #52523)
[Link]
> the ash-heap of history is littered by companies and organizations that have decided that everyone else was wrong, and they knew better and could design such a great system that everyone else would abandon what they use to jump on board.
And with even more companies that decided to "stick to standards" and stop innovating (e.g. basically all commercial UNIX vendors).
> You act as if the POSIX (and Single Unix Specification) standard is something handed down from on high that hasn't changed in 20 years.
Yep. Not much has changed in important areas, changes are mostly cosmetic (and yes, we've actually paid for copies of official POSIX standards).
For example, my another pet peeve - signals are useless for library writers because there's no mechanism to allocate/reserve them or to pass parameters to a signal handler.
> The last revision to POSIX and SUS took place within the last couple of years, and the next one will take place within the next few years.
Will it include cgroups, namespaces, kqueue? No?
> The problem isn't with the idea of enhancing things, it's with the idea that standards don't matter, nobody else matters, only develop for yourself and to #$% with everyone else.
And yet, the recent history shows us that this very attitude works. Most "community projects" end up dead after extensive bike-shedding flamewars.
log why the permission is denied
Posted Jan 20, 2013 14:17 UTC (Sun) by RobSeace (subscriber, #4435)
[Link]
> For example, my another pet peeve - signals are useless for library
> writers because there's no mechanism to allocate/reserve them or to pass
> parameters to a signal handler.
You may wish to look into sigaction(SA_SIGINFO) and sigqueue() used with POSIX.1b real-time signals... That at least solves your second issue... As for your first, I'd think just using sigaction() to peek at the current handler would tell you if a signal is currently already in use or not...
log why the permission is denied
Posted Jan 20, 2013 1:00 UTC (Sun) by dvdeug (subscriber, #10998)
[Link]
No, it would only require modifying applications that care to produce better error messages. Any solution that gets better error messages to the users is going to require modifying applications.
With all due respect to *BSD maintainers, I don't see it. Lots of stuff uses udev, despite it being Linux-only. If you want to provide decent error messages to the majority of your users, you'll support it; if you don't care, then you won't.