Yes, but that's just land you can buy. You don't get to write the laws or anything. It's just a big chunk of private property. If Canadian law prevents you from flying an F/A-18, you're still screwed.
Have you ever seen XP Home? You don't have access to the W2K-style users and groups MSC plugin. There really are only two account types for users: administrator and crippled. Oh, and I think there's a "guest" account you can activate. I don't know if the full API is still there and you just need a third party app, but at least by default it's not easy to create non-admin users that can actually do anything.
Huh? Any light truck is also very "nuclear capable". If the US is serious about protecting its people from nuclear weapons, it needs to go after the weapons themselves. But since it insists on keeping so many of them for itself, it has no credibility...
We've tried getting rid of some of the extensions that were not well thought out. He's [RMS] just dead-set on keeping them.
But how much code does RMS contribute to GCC? Shouldn't GCC, like other OSS projects, ultimately be in the hands of its developers?
Also -- unfortunately -- many of them are actually being used. Pulling the rug out from under your users is not a keen move.
I fully understand that. That's why I suggest leaving them in but requiring flags to activate them. Then you can give errors like obsolete extension >? requires -fminmax-operators. If users don't want to change their code, they can add some flags.
Isn't this the sort of thing that we'd be up in arms about if it were MS compiler quirks other compilers were emulating? The GCC compilers should make strict conformance to modern standards the default, and make you turn on the extensions manually.
Why, for example, does GNU C++ include binary <? and >? operators for min and max? I could see the attraction in C, where preprocessor macros and their issues with side effects are a pain in the ass. But in C++, inline templated functions can do it just as well and are much more portable. This is the sort of irresponsible "extend the language by default" approach that the GCC compilers are full of.
Don't get me wrong; I love the GCC suite and for all the supposed performance issues, I wouldn't trade GCC for any other toolchain I've ever used. But free software should set an example by encouraging portable code.
In a regular OS you have to allow the Apache some root control over the computer to have it work properly and a hacker can use this to violate your computer.
No, it just has to start as root if you want it to bind to a privileged TCP port like 80. Very few servers require root access once they bind. Apache, like many other daemons, can be run as an unprivileged user in a restricted chroot jail.
Posix has had resource limits for a long time now. See setrlimit(2), for example. PAM has had a module to support this for quite a while. I'm sure Solaris has resource limits. Virtualization (what the N1 system seems to be) is a whole different beast, with different uses. If all you want is to stop a script from eating all the CPU, any Unix will do that for you.
It would be more than that, at least from what the description suggests. The problem with sudo is that you're often giving suid access to programs that aren't designed to be suid, so someone who was the right entries in the sudoers file can root the machine with ease. Proper privilege separation in the admin tools would mean being able to give someone access to run apt-get dist-upgrade (or whatever it is) without his being able to install his own packages. It would mean letting someone add non-root users but not root users, or resetting passwords but only for users in a certain group. It requires planning when creating admin tools, not a "slap it on" solution like sudo.
Of course, given that it's Solaris, it may end up just being sudo after all.
I saw that a while ago (years ago?) and went back a few minutes ago to compare it against the list of files that someone else posted a link to. But it was obvious when I first saw it, and it's apparently been confirmed now, that this it is by no means the full tree. OTOH, what was leaked today might actually be the full tree.
Actually, the early Soviet spacecraft didn't actually land; they just lied about that. Rather, the occupant was blasted out by an ejection seat when the capsule fell to a certain altitude.
Have you ever seen an American car dealership? Imagine a small castle of a dealership building surrounded, as far as the eye can see, by fields of shining cars waiting to be hawked. A roof would have to be huge, and would need to contain enough lighting to keep the whole lot brightly lit during the day.[1] Not only that, it would either need to be closed off (at which point you're basically paying for a warehouse--and on a sunny day, who wants to go car shopping in a warehouse), or extended beyond the ends of the car lots, because hail doesn't always fall straight down; hailstorms tend to be associated with wind as well.
So a fucking roof would actually be quite expensive; it's almost certainly cheaper to just insure the cars against hail damage. Now, that still doesn't excuse falling for a snake oil scheme.
[1] Actually most car dealerships already are (at night) brighter than the sun, but they don't pay to keep those lights on during the day.
DRM simply doesn't work without hardware cooperation. The only way it can pretend to work otherwise is if all the software is closed and under the control of the DRM implementors. In an OSS, that would never work. Please--get a clue before posting.
The 68K family is big-endian, but the ARM family is little-endian as used in Palm OS systems. Now I wasn't aware they could have used it as a big-endian chip; was there some disadvantage that might have prevented them from doing it?
(As to the spelling, I bow my head in shame.)
Developers, developers, developers, developers
on
Palm Changing OS Strategy
·
· Score: 4, Insightful
PalmSource has made a mess of the platform from a developer's perspective. It used to be that all Palm OS systems were more or less the same--slow 68k processor, very small address space, small 160x160 monochrome touch screen. As the technology moved down in price, Palm OS systems started to get improvements like faster ARM processors (endian change!), more memory, and high resolution color screens. The problems are several:
The hardware became too varied. Palm OS form resources use absolute positioning, so it's not easy designing a form for different screen resolutions. Having multiple copies of each form is a pain in the ass, both when creating the forms and when writing the code.
The APIs became fragmented. Until recently, every device manufacturer with a resolution above 160x160 (or a collapsable input area) had its own API. Some developers of 3rd party apps go out of their way to support all of these--but most just support none.
The development tools became too complicated. POSE was great, but now every device seems to requires its own emulator or simulator. Not every simulator makes it to every development platform. It becomes a pain in the ass to test for all the devices out there.
Backwards compatibility was either overpursued or underpersued. For the former, consider sysAppLaunchCmdFind. Find is enormously painful to support--no globals, no exceptions, etc. But with the amount of memory in today's machines, there's no reason this launch code can't be accompanied by globals. Then in apps I can't be bothered supporting Find in, I'd be more likely to write the code--though it would only run if I had a launch flag to tell me my globals are present (sysAppLaunchFlagNewGlobals | sysAppLaunchFlagSubCall). For a lack of backwards compatibility, look at VFS.
So in summary, life has been frustrating for Palm OS developers. But the real losers here are the users. What used to be a vibrant community of 3rd party developers has somewhat dried up. People simply aren't writing as many good, device-neutral Palm OS apps as they used to.
Slashdot Mirror
When you win an election in a "democratic republic", you win with 100% of the vote, or 99% if you're feeling magnanimous.
Yes, but that's just land you can buy. You don't get to write the laws or anything. It's just a big chunk of private property. If Canadian law prevents you from flying an F/A-18, you're still screwed.
Have you ever seen XP Home? You don't have access to the W2K-style users and groups MSC plugin. There really are only two account types for users: administrator and crippled. Oh, and I think there's a "guest" account you can activate. I don't know if the full API is still there and you just need a third party app, but at least by default it's not easy to create non-admin users that can actually do anything.
Remember back when we used to laugh at the idea that reading an email message would give your computer a virus?
Huh? Any light truck is also very "nuclear capable". If the US is serious about protecting its people from nuclear weapons, it needs to go after the weapons themselves. But since it insists on keeping so many of them for itself, it has no credibility...
Well, one is much easier to fly out of your back yard than the other. That is, unless you have a runway on your lot.
I can see the advertising now: "more fuel-efficient than an SUV!"
Where? And one with a runway good enough for a military jet? Give me a link, or give me a break.
Yeah, because people aren't riled up at Bush enough quite yet. Maybe they'll start burning him in effigy in America as well.
But how much code does RMS contribute to GCC? Shouldn't GCC, like other OSS projects, ultimately be in the hands of its developers?
I fully understand that. That's why I suggest leaving them in but requiring flags to activate them. Then you can give errors like obsolete extension >? requires -fminmax-operators. If users don't want to change their code, they can add some flags.
Isn't this the sort of thing that we'd be up in arms about if it were MS compiler quirks other compilers were emulating? The GCC compilers should make strict conformance to modern standards the default, and make you turn on the extensions manually.
Why, for example, does GNU C++ include binary <? and >? operators for min and max? I could see the attraction in C, where preprocessor macros and their issues with side effects are a pain in the ass. But in C++, inline templated functions can do it just as well and are much more portable. This is the sort of irresponsible "extend the language by default" approach that the GCC compilers are full of.
Don't get me wrong; I love the GCC suite and for all the supposed performance issues, I wouldn't trade GCC for any other toolchain I've ever used. But free software should set an example by encouraging portable code.
</rant>
No, it just has to start as root if you want it to bind to a privileged TCP port like 80. Very few servers require root access once they bind. Apache, like many other daemons, can be run as an unprivileged user in a restricted chroot jail.
Posix has had resource limits for a long time now. See setrlimit(2), for example. PAM has had a module to support this for quite a while. I'm sure Solaris has resource limits. Virtualization (what the N1 system seems to be) is a whole different beast, with different uses. If all you want is to stop a script from eating all the CPU, any Unix will do that for you.
It would be more than that, at least from what the description suggests. The problem with sudo is that you're often giving suid access to programs that aren't designed to be suid, so someone who was the right entries in the sudoers file can root the machine with ease. Proper privilege separation in the admin tools would mean being able to give someone access to run apt-get dist-upgrade (or whatever it is) without his being able to install his own packages. It would mean letting someone add non-root users but not root users, or resetting passwords but only for users in a certain group. It requires planning when creating admin tools, not a "slap it on" solution like sudo.
Of course, given that it's Solaris, it may end up just being sudo after all.
I saw that a while ago (years ago?) and went back a few minutes ago to compare it against the list of files that someone else posted a link to. But it was obvious when I first saw it, and it's apparently been confirmed now, that this it is by no means the full tree. OTOH, what was leaked today might actually be the full tree.
You mean:
>>MEN: SC0 grows your BU.SI NESS ! ! pineapple verbatim halliburton
The Israeli/Palestinian experts in the Bush administration sure seem to think so.
It's just the engineers trying to get sexed up.
Have you ever seen an American car dealership? Imagine a small castle of a dealership building surrounded, as far as the eye can see, by fields of shining cars waiting to be hawked. A roof would have to be huge, and would need to contain enough lighting to keep the whole lot brightly lit during the day.[1] Not only that, it would either need to be closed off (at which point you're basically paying for a warehouse--and on a sunny day, who wants to go car shopping in a warehouse), or extended beyond the ends of the car lots, because hail doesn't always fall straight down; hailstorms tend to be associated with wind as well.
So a fucking roof would actually be quite expensive; it's almost certainly cheaper to just insure the cars against hail damage. Now, that still doesn't excuse falling for a snake oil scheme.
[1] Actually most car dealerships already are (at night) brighter than the sun, but they don't pay to keep those lights on during the day.
But now that you've grown up, you realize that was just thunder, right? Right?
DRM simply doesn't work without hardware cooperation. The only way it can pretend to work otherwise is if all the software is closed and under the control of the DRM implementors. In an OSS, that would never work. Please--get a clue before posting.
Lyrics are from Same Thing, from Born On A Pirate Ship. They don't appear on Stunt.
The 68K family is big-endian, but the ARM family is little-endian as used in Palm OS systems. Now I wasn't aware they could have used it as a big-endian chip; was there some disadvantage that might have prevented them from doing it?
(As to the spelling, I bow my head in shame.)
PalmSource has made a mess of the platform from a developer's perspective. It used to be that all Palm OS systems were more or less the same--slow 68k processor, very small address space, small 160x160 monochrome touch screen. As the technology moved down in price, Palm OS systems started to get improvements like faster ARM processors (endian change!), more memory, and high resolution color screens. The problems are several:
So in summary, life has been frustrating for Palm OS developers. But the real losers here are the users. What used to be a vibrant community of 3rd party developers has somewhat dried up. People simply aren't writing as many good, device-neutral Palm OS apps as they used to.