Didn't we just read that chroot "jails" are not secure?
Only when you have full shell access. This patch is just about confining sftp file transfers via chroot(2) for some users without the burden of setting up a full chrooted environment. Sounds really sweet.
Re:My only suggestion for X
on
X Power Tools
·
· Score: 2, Informative
This isn't a troll; monitors and graphics cards have been able for donkeys years to tell the OS what resolutions and refresh-rates they are capable of for years now and X hasn't caught on.
Uh? Xorg (and XFree86 before) have been querying monitors characteristics via DDC for years. HorizSync and VertRefresh are just for really ancient monitors/graphic adapters. Look here if you don't believe me.
I'm just curious how you ran uptime with no users logged in?
Just ssh user@host uptime.
SSH does not perform a real "login" (in the sense of allocating a pty and writing in utmp) when specifying a remote command to execute. Thus, havin zero users loggged in is normal in that case. Try it yourself.
Honestly, it reminds me a lot of the Fiat 500 of 50 years ago, which was a notable success in post-war Europe: a two-cylinder engine, small and tiny wheels, small footprint, cheap and affordable... perhaps other similarities. Tata's car could never stay cheap and meet the safety and environmental requirements for today's western world, but a car like that seems perfect in developing areas.
Oh, and the bit about the huge Target parking lot is mostly true, but that's what you get when living in a place which has insufficient public transportation (it varies from place to place, though) and more than six times the population density of the U.S.A. (India is almost ten times...)
Why on Earth would you ever discuss sensitive information on the phone before? There's always been phone tapping tech. It's only the laws for that technology's usage that protected anyone from it. You never say anything on the phone that you wouldn't say to a cop. If you don't know that rule, you're a pretty inept criminal.
by no means discussing "sensitive" information does imply underlying illegal activities (even if it is the case sometimes);
there are a lot of details everyone would tell a cop if requested to, but would not reveal in a public place. Having the cops hearing your business plans is not the same as your competitors hearing them.
also you can rightfully expect the cops not to reveal your business plans to your competitors even after.
As low as it may be, there still is some expectation of privacy on the phone (that's why wiretapping is regulated by a law): unfortunately even that low barrier has been broken in a quite spectacular way, so people now are outraged and asking for end-to-end encrypted phones, since they can't trust the phone company (the tapping apparently was done by insiders at the phone company...).
No, having the patents of course protects MS claims to only yhe specific aspects of the product covered by those patents.
Hmmm... owning the patents offers more protection than that: assuming you had a legitimate patent on somehting and found Microsoft infringing it, you'd have to think twice before suing Microsoft, because if you sued, you'd instantly lose any right Microsoft previously gave you to implement aspects covered by the Microsoft patents (and Microsoft could then rightfully sue YOU for patent infringiment).
If the Microsoft patents were put in the public domain, you couldn't lose that rights, and you wouldn't have to think twice before suing Microsoft.
So, it's clear where the convenience is for Microsoft.
Releasing the patents into the public domain would have the same effect.
But that would protect just the specific aspects of a product which were covered by said patents, but it tells nothing about other aspects that could be (wrongfully) patented by others.
In other words: Microsoft is not saying "If you sue me on that patents, you can't use them anymore", but is really saying "If you sue me, you can't use that patents anymore".
To be really equivalent, Microsoft would have to absolutely patent every aspect of its products, then release said patents into the public domain, and then we'd still need a flawless patent system to ensure that any bogus claim by others is thrown out from the start...
Question for you: how would you do that across multiple files in emacs?
Use dired on the directory where files are located (i.e. M-x dired), mark the files you are interested in (with 'm'),
then use 'Q' (uppercase) to perform what basically is a query-replace-regexp on all
the marked files (actually it is dired-do-query-replace-regexp).
See the GNU Emacs dired documentation for further details.
Ubuntu will not include this plugin by default, last I checked. It was discussed to death on the devel mailing list.
I'm sorry, you are right: I thought the only issue was the exception to the GPL programs linking to GStreamer, and seeing it available in the Debian archives I believed that was already sorted out. I didn't realize there were other issues.
Not really a reason to avoid PostgreSQL, but its default non-ANSI SQL way of quoting characters in string constants (using also backslashes) is for me a major annoyance when developing cross-RDBMS applications (yes, I already know of PQescapeString()).
Fortunately, PostgreSQL developers recognized this is more of an annoyance than a feature, and are going to change the default behaviour in PostgreSQL 8.2 (while preserving the old behaviour using a new syntax).
Yet the whole point of signing the binary is exclusively identifying it as coming from Bluehat.
So GPLV3 effectively prevents digital signatures from being used to determine if a binary may be from a source the user trusts!
Sorry, but for the way you put it, the whole point is to prevent the Mactel motherboard from running anything not signed from Bluehat, which is just one of the ways users can "check" that a binary is signed from Bluehat.
On the other hand, with commented code they are dealing with two similar but distinct things
IMHO, the point of comments is not to tell other how things are done, but why they have been done in that specific way. No amount of code can tell you that.
Just a note: your point is absolutely valid and correct, but please don't use Bash as an example, because it is one of the few cases where this don't work. Bash always resets the effective user ID to the real user ID, basically making it impossible to have a setuid bash.
Of course it will work with other shells and programs that can start commands.
At the risk of being flamed mightily, what's wrong with IE?
Its rendering engine is intentionally not available to non-Microsoft platforms, and it has several peculiarities when compared to other rendering engines which makes harder developing a website that is at the same time pleasant and actually usable by all major browsers out there. In the view of its dominant position, this means promoting the development of IE-only websites (because, guess what, it is cheaper to develope for just a single known target).
IE-only websites currently translates also to Microsoft Windows-only websites (it wasn't so in the past: there has been IE "ports" for Solaris and HP-UX, and a version for MacOS X which has been discontinued days ago).
For obvious reasons, that's bad in the short term for the Microsoft competitors, and is bad for web developers and users in the long term because it puts Microsoft competitors and people willing to develope cross-browser websites completely out of the market.
You know that there can't be a free market without competition, and I'd go as far to say it took the release of both Firefox and Safari to convince Microsoft it was definitively the time to reassemble an IE development team and to start fixing also non-security related bugs.
So, to summarize: there's nothing bad in IE itself (bugs aside), except it is higly instrumental in imposing Microsoft's policy down the trhoat of everyone willing to surf the web. Users are just the last ones cosciently being impacted by Microsoft choices, so that doesn't seem a problem to them; nonetheless they are impacted at some point, but usually when it's too late.
What's so great about it that people insist on using it rather than any other editor?
It runs on any platform out there, and in the exact same way. Learn Emacs once, use it forever;
while it is somewhat long to learn, you do just everything without needing to move your hands from the keyboard, and without needing to watch the screen. I can't stress this point enough;
it's higly customizable (really: M-x customize, and have a look for yourself);
provides specialized modes for basically every language out there;
being a Lisp machine, it's just natural to extend it, starting with little ad-hoc ELisp snippets, which sometimes turn into whole ELisp packages;
it has been out there for almost 30 years, refined year by year by generations of users. There is a lot of know-how and good sense in it.
The only other editors I'd consider would be Vim (because if Emacs is lightweight by today's standards, Vim is even lighter -- but then, there's also Zile), and JEdit (because it is the only one that comes close in functionality).
Now if they could only make it so I don't have to restart Firefox every time I install a new extension.
Apples and oranges here: the main point about a web browser is browsing, not installing extensions.
The main point about an OS is to make the system available to its users, and keep it available as much as possible.
Being able to perform most OS upgrades without requiring dozen of users to stop their activities is fundamental for a healthy multiuser system. Being able to install/unistall Firefox extensions on the fly would be nice, but is not as nearly as critical.
Since the X server can't deal (yet?) with compressed pixmaps by itself, and since we don't want to store the uncompressed pixmaps offscreen in the X server because it takes memory, the only way to do this is to have the application to uncompress the pixmaps on the fly and upload the needed bits to the X server each times it needs them.
That's fine when the X server and the application are on the same host, but it is less than ideal when the X server is on a different host (you really want to send the data just once in this case). It's probably better to have it both ways.
Possible outcomes:
applications could do that by themselves via specific support in the toolkit (i.e. let GTK+, Qt and FLTK deal with it)
the X server could transparently (read: internally, with neither the applications nor the toolkits knowing of it) compress pixmaps uploaded to it, uncompressing them when needed (really bad, because the X server would also have to compress them)
the X protocol could be extended to deal with compressed pixmaps (the X server would have just to uncompress them, but that's a new extension and the applications/toolkits need to be modified to use it)
leave everything as it is, assuming that X servers mainly run on systems providing virtual memory, which is quite cheap (bad for small/embedded devices)
Only when you have full shell access. This patch is just about confining sftp file transfers via chroot(2) for some users without the burden of setting up a full chrooted environment. Sounds really sweet.
This isn't a troll; monitors and graphics cards have been able for donkeys years to tell the OS what resolutions and refresh-rates they are capable of for years now and X hasn't caught on.
Uh? Xorg (and XFree86 before) have been querying monitors characteristics via DDC for years. HorizSync and VertRefresh are just for really ancient monitors/graphic adapters. Look here if you don't believe me.
Thanks, I did't know of "disown".
Just ssh user@host uptime.
SSH does not perform a real "login" (in the sense of allocating a pty and writing in utmp) when specifying a remote command to execute. Thus, havin zero users loggged in is normal in that case. Try it yourself.
Oh, and the bit about the huge Target parking lot is mostly true, but that's what you get when living in a place which has insufficient public transportation (it varies from place to place, though) and more than six times the population density of the U.S.A. (India is almost ten times...)
No.
What Ballmer is saying is that the Zune's target market is old people.
He's probably planning to sell it to old people in Korea.
By email, of course.
As low as it may be, there still is some expectation of privacy on the phone (that's why wiretapping is regulated by a law): unfortunately even that low barrier has been broken in a quite spectacular way, so people now are outraged and asking for end-to-end encrypted phones, since they can't trust the phone company (the tapping apparently was done by insiders at the phone company...).
No, having the patents of course protects MS claims to only yhe specific aspects of the product covered by those patents.
Hmmm... owning the patents offers more protection than that: assuming you had a legitimate patent on somehting and found Microsoft infringing it, you'd have to think twice before suing Microsoft, because if you sued, you'd instantly lose any right Microsoft previously gave you to implement aspects covered by the Microsoft patents (and Microsoft could then rightfully sue YOU for patent infringiment).
If the Microsoft patents were put in the public domain, you couldn't lose that rights, and you wouldn't have to think twice before suing Microsoft.
So, it's clear where the convenience is for Microsoft.
Releasing the patents into the public domain would have the same effect.
But that would protect just the specific aspects of a product which were covered by said patents, but it tells nothing about other aspects that could be (wrongfully) patented by others.
In other words: Microsoft is not saying "If you sue me on that patents, you can't use them anymore", but is really saying "If you sue me, you can't use that patents anymore".
To be really equivalent, Microsoft would have to absolutely patent every aspect of its products, then release said patents into the public domain, and then we'd still need a flawless patent system to ensure that any bogus claim by others is thrown out from the start...
Use dired on the directory where files are located (i.e. M-x dired), mark the files you are interested in (with 'm'), then use 'Q' (uppercase) to perform what basically is a query-replace-regexp on all the marked files (actually it is dired-do-query-replace-regexp).
See the GNU Emacs dired documentation for further details.
I'm sorry, you are right: I thought the only issue was the exception to the GPL programs linking to GStreamer, and seeing it available in the Debian archives I believed that was already sorted out. I didn't realize there were other issues.
Not really a reason to avoid PostgreSQL, but its default non-ANSI SQL way of quoting characters in string constants (using also backslashes) is for me a major annoyance when developing cross-RDBMS applications (yes, I already know of PQescapeString()).
Fortunately, PostgreSQL developers recognized this is more of an annoyance than a feature, and are going to change the default behaviour in PostgreSQL 8.2 (while preserving the old behaviour using a new syntax).
Fluendo has released a licensed MP3 plugin for the GStreamer framework. It's already in Debian unstable, and I'd say Ubuntu probably will include it.
So GPLV3 effectively prevents digital signatures from being used to determine if a binary may be from a source the user trusts!
Sorry, but for the way you put it, the whole point is to prevent the Mactel motherboard from running anything not signed from Bluehat, which is just one of the ways users can "check" that a binary is signed from Bluehat.
What about OCFS and OCFS2?
IMHO, the point of comments is not to tell other how things are done, but why they have been done in that specific way. No amount of code can tell you that.
Just a note: your point is absolutely valid and correct, but please don't use Bash as an example, because it is one of the few cases where this don't work. Bash always resets the effective user ID to the real user ID, basically making it impossible to have a setuid bash.
Of course it will work with other shells and programs that can start commands.
Also the ones redistributing unmodified binary versions. Pointing to someone else's FTP server for the sources is not enough to comply with the GPL.
Its rendering engine is intentionally not available to non-Microsoft platforms, and it has several peculiarities when compared to other rendering engines which makes harder developing a website that is at the same time pleasant and actually usable by all major browsers out there. In the view of its dominant position, this means promoting the development of IE-only websites (because, guess what, it is cheaper to develope for just a single known target).
IE-only websites currently translates also to Microsoft Windows-only websites (it wasn't so in the past: there has been IE "ports" for Solaris and HP-UX, and a version for MacOS X which has been discontinued days ago).
For obvious reasons, that's bad in the short term for the Microsoft competitors, and is bad for web developers and users in the long term because it puts Microsoft competitors and people willing to develope cross-browser websites completely out of the market.
You know that there can't be a free market without competition, and I'd go as far to say it took the release of both Firefox and Safari to convince Microsoft it was definitively the time to reassemble an IE development team and to start fixing also non-security related bugs.
So, to summarize: there's nothing bad in IE itself (bugs aside), except it is higly instrumental in imposing Microsoft's policy down the trhoat of everyone willing to surf the web. Users are just the last ones cosciently being impacted by Microsoft choices, so that doesn't seem a problem to them; nonetheless they are impacted at some point, but usually when it's too late.
The only other editors I'd consider would be Vim (because if Emacs is lightweight by today's standards, Vim is even lighter -- but then, there's also Zile), and JEdit (because it is the only one that comes close in functionality).
Technically, it's Emacs 1.22, but the leading 1 has been dropped ages ago (no major incompatibilities, just new features...).
Apples and oranges here: the main point about a web browser is browsing, not installing extensions.
The main point about an OS is to make the system available to its users, and keep it available as much as possible.
Being able to perform most OS upgrades without requiring dozen of users to stop their activities is fundamental for a healthy multiuser system. Being able to install/unistall Firefox extensions on the fly would be nice, but is not as nearly as critical.
Please reconsider your priorities.
I'd rather let Nomachine NX deal with the optimizations of X protocol transfers.
That's fine when the X server and the application are on the same host, but it is less than ideal when the X server is on a different host (you really want to send the data just once in this case). It's probably better to have it both ways.
Possible outcomes: