Incidentally, I'm an xCAT developer and am always interested in ways to make it scale down a bit better as well as it scales up. Historically, it has been worth it at large scale, but a bit too much configuration for small systems. A lot of settings support autodetect now and if you don't care much about the nitty-gritty, applying the default templates provides a serviceable set of groups that can drive configuration instead of micromanaging all sorts of details.
In terms of DHCP, it generally allows and uses nice features of ISC DHCP without requiring more complex config than dnsmasq, which is probably one of the nicer things it does. Notably if you are doing iSCSI, deploying Windows, want a nfs or ramroot system, or other fancy stuff xCAT does a good job of taking care of the requisite details (I'm a bit biased).
I'm always interested in other ways to make it easier or criticisms on how it's deficient. Preferably on the xcat-user mailing list.
But delta rpms are nice and I don't know (haven't seen) equivalent stuff crop up in apt. apt/deb was light-years ahead in the beginning, but yum/rpm has more or less caught up and even has some nice stuff missing from apt/deb (though yum incessantly refreshing the metadata by default annoys me personally, increasing time to install a package unnecessarily).
So as one who is fairly chaotic about app install, I never liked/used menus anyway, so pressing Meta, then starting to type what I want is natural. It's a fancier run dialog for me in essence.
My problem is I'm similarly chaotic about opening many windows, many tabs, many applications. Compiz and KDE4 has it just right, I can search and it will remove from the scaled window display any windows that do not match the search string. KDE and Windows 7 offers a weaker, but distinctly useful alternative of previewing all windows associated with an app icon. With only those two capabilities (the window preview on mouseover in the activities view acting like Unity on mouse click), I could get behind Gnome 3. Well, that and the ability to customize keyboard shortcuts, I have way too many nested remote desktop scenarios to conveniently take defaults (and I just prefer some things).
It is all but impossible to 'accidentally' put your car in reverse instead of drive. Think about the number of times you hear a story about someone who did just that.
Point taken, except in a Volkswagen that puts reverse next to first (yeah, allegedly you have to push down and so it *should* be difficult, but I've ridden with enough people who make that mistake to be dubious).
I understand that the GPL allows some recoup of costs for development and distribution, but at all times the source must be available for free.
Actually, you only *need* to provide source to those who you provide binaries. So if your binaries require 20 dollars, you must provide the source to anyone who legitimately gets your binaries, but no more.
Of course, they can subsequently turn around and redistribute your source at will.
Cars: getting rid of stick shifts despite better fuel mileage and better safety
On mileage, CVT kinda throws a kink in the 'manuals are more efficient' argument. I'm not sure what's particularly safer about a stick shift, though I might buy more reliable on average. I think driving stick is more fun, personally.
I don't care *who* 'wants' it, Google is going along with it (and has been going along with it from even before movie studios were involved). The whole reality that one has to root/jailbreak your phone means the vendor is not being completely open.
Though less 'open', WebOS at least gives end users more sanctioned control over their device. You enter a well-documented code to enable the option to provide root shell and sideload applications. Too bad they have not seen success in the market, *but* I would encourage people seeking a device that gives them control to consider it a haven from iOS, Android, BalckBerry, and WP7 devices. I personally will only buy a phone that needs such BS as 'jailbreaking' when I simply have no option left. I don't care how 'easy' it is *unless* the manufacturer comes right out and officially says "here you go, we have no intent on restricting you in the future, have fun" (see http://developer.palm.com/blog/2011/05/10-reasons-for-geeks-to-love-hp-webos/ number 2). I don't want to be stuck in a fight with the company I gave money to for the duration of my ownership of it.
OpenMoko also is open *and* gives ultimate control, but unfortunately is a pretty impractical platform for a lot of the stuff people want to do with their handheld devices.
Funny, people can play this content on their personal computers. I too am dissatisfied with Linux support, but anyone claiming they don't support Linux it's due to DRM is full of it. So long as they let a Windows PC (which gives the users administrative access) play back the content, the argument is moot.
For example, say I want to start allowing port 22: iptables -I INPUT -p tcp --dport 22 -j ACCEPT
That is not restarting firewall while users were using the system. I may have to do some juggling if I want the rule in the middle.
On a related note, I've always detested redhat firewall configuration for making more chains than needed for their straightforward configuration, making the rules appear far more complicated than they are.
Generally, linux desktop INPUT firewalls strike me as superfluous. That said, there is one use case, filtering out ports higher than 1024 from listening. This would mean any socket acting server-like would have to be explicitly blessed by someone with admin rights, which could mitigate certain types of trojan attacks.
What cracks me up is all these firewalling rules being automatically removed and inserted by installing the relevant application. For example install openssh and the firewall magically gets a rule to allow port 22. *This* is particularly asinine and is the sort of thing worthy of ridicule. If they can listen on a privileged port, they could change firewall rules, so filtering INPUT below 1024 for fear of malware is stupid (though it is a useful workaround for crappy apps without sufficient configurability to bind to specific interfaces).
Kind of, but with mouseover instead of click, which is not feasible for Unity (and unity does something weird if you are previewing one app and click on another running app).
Basically, gnome-shell makes it easy for mouseover to work because you've already entered a task-switching mode, so changing the preview windows based on current mouseover would be easier.
That's of course only one half, the window title search is still foreign.
Unity still has some quirky behavior, and frankly I'm just not a fan in general.
Gnome-shell is close, yet far away. It's more extensible seems like, which is promising. I just want two things: -When I highlight an 'application icon' in the activities view, automatically show only the windows for that application in the window previews. -Provide a means by which I can start typing and search window title bar contents (like KDE and Compiz Window Title Filter).
You have me sold on those two capabilities, which don't seem to exist. The gnome-shell-extensions have most of my other main requests covered.
Ok, guess I really meant: "That means productivity apps like OpenOffice/etc will also work"
was inaccurate because it implied because of.Net and/or CLR that OpenOffice would work when in reality it's because it's FOSS and it'd be trivial to do.
If a game costs 10 bucks new, not much of a secondary market. At least none that a Gamestop like company would have enough wiggle room to bother with. There might be a craigslist here and there, but no business in trade-in games. If you planned at doing $50 at your volume moves up by five-fold, revenue wise it's a wash, your game is more popular, and given the margins in software distribution your profit is probably the same too.
Similarly, the relative hassle/risk of pirating a game isn't appealing if you can just get legally licensed for a trivial sum.
The problem here is that generally means knowing the hash is just as good as knowing the password. This is the point most of the people employing that strategy miss. It may prevent an attacker from sitting at a keyboard using to blessed interface, but their own client modded to send the hash without even prompting for a password would be no better.
I doubt I'll ever trust a service providers storage encryption rather than applying a local, independent layer of encryption they can't circumvent, *however*, it isn't entirely unreasonable to believe a cloud solution could include meaningful encryption that would preclude even their administrators from access, *even* in the dropbox case with files being shared. Granted, doing so and doing it conveniently means they probably have an exposure (I wager that the client software submits the password to server for authentication and therefore a modified server could capture password and use that to decrypt keys, which is the most straightforward thing to expect), but doing it privately is not impossible (e.g. shift auth to send down a prospective client the private key, protected by passpharse encryption, and the ability to answer a challenge serving as proof of password with the server retaining nor ever receiving at any time neither password or the key in the clear).
All that said, I'll continue to use local GPG keys on any data I host anyware that I remotely care about. If I need to share, then I'll employ the public keys of those I need to share with. Taking security into your own hands *as well* as any protections offered by the storage provider is always your best bet.
I suspect most all of the people that are amazon customers only vaguely know what's going on and won't bother to learn the detail on the hosting provider for the attackers systems.
I suspect the minority that are that inclined almost all know that in this specific scenario, Amazon was just a hosting provider and understand that means they aren't particularly responsible for what happened any more than AT&T would be responsible for a house downloading a video illegally.
Sure, there is probably a very small population that will stumble upon the facts and falsely presume Amazon is an evil company for cracking into Sony's stuff (as opposed to an evil company for other reasons). I have a feeling that change in revenue would be lost in the noise and small compared to any arbitrary boycott over seemingly small and/or inane things Amazon does on any given day.
I think you'd have to show that Amazon was *knowingly* selling the product afoul of your copyright (or patent if it's a machine or something) in order for Amazon to have some share of liability. Regardless of whether Amazon has any liability, you go after 'TheftCo' for wilfully violating your copyright.
This problem is hardly new as of electronic distribution, and there's zero reason to treat it any differently than if the problem happened in a brick and mortar bookstore.
The authors can get their own hosting and handle their own storefront. Kindle, Apple, B&N, Kobo, etc have *no* lock-in where you have no choice but to buy from their store. An author can gleefully put up their own and sell (though if they want DRM on Kindle, then yes Amazon is the only way, but you sad yourself you didn't want DRM).
I happen to have a Kobo, but it would be no different if I had a Kindle. I have a vast minority of books purchased through Borders or Kobo, almost everything was gotten through other sources like Baen.
So if you are into selling Yaoi, then just make it clear it can't be bought through Amazon *and* provide an alternative instead of just whining. I'm sure your customers will notice the lack of their genre being available and do a web search and come across your explanation of the issue and the way to send money *directly* to you for purchase.
Maybe *you* don't know your password, but there is a good chance that the attackers can crack their copy of the hash and know your password. Resalting does precisely nothing because the danger is the attackers getting your password, and once they have that, any salt you apply will make no difference.
Slashdot Mirror
Currently supports RHEL, spotty support for Fedora, Scientific Linux, CentOS, SuSE Linux Enterprise 11, Windows 2008 and up, and ESXi 4 and up.
Debian and Ubuntu have made appearances in trunk, but I haven't tried it out personally yet.
Incidentally, I'm an xCAT developer and am always interested in ways to make it scale down a bit better as well as it scales up. Historically, it has been worth it at large scale, but a bit too much configuration for small systems. A lot of settings support autodetect now and if you don't care much about the nitty-gritty, applying the default templates provides a serviceable set of groups that can drive configuration instead of micromanaging all sorts of details.
In terms of DHCP, it generally allows and uses nice features of ISC DHCP without requiring more complex config than dnsmasq, which is probably one of the nicer things it does. Notably if you are doing iSCSI, deploying Windows, want a nfs or ramroot system, or other fancy stuff xCAT does a good job of taking care of the requisite details (I'm a bit biased).
I'm always interested in other ways to make it easier or criticisms on how it's deficient. Preferably on the xcat-user mailing list.
Hence the qualifier 'personally'. Some people enjoy playing baseball, some people enjoy golf, some intrinsically enjoy driving.
But delta rpms are nice and I don't know (haven't seen) equivalent stuff crop up in apt. apt/deb was light-years ahead in the beginning, but yum/rpm has more or less caught up and even has some nice stuff missing from apt/deb (though yum incessantly refreshing the metadata by default annoys me personally, increasing time to install a package unnecessarily).
So as one who is fairly chaotic about app install, I never liked/used menus anyway, so pressing Meta, then starting to type what I want is natural. It's a fancier run dialog for me in essence.
My problem is I'm similarly chaotic about opening many windows, many tabs, many applications. Compiz and KDE4 has it just right, I can search and it will remove from the scaled window display any windows that do not match the search string. KDE and Windows 7 offers a weaker, but distinctly useful alternative of previewing all windows associated with an app icon. With only those two capabilities (the window preview on mouseover in the activities view acting like Unity on mouse click), I could get behind Gnome 3. Well, that and the ability to customize keyboard shortcuts, I have way too many nested remote desktop scenarios to conveniently take defaults (and I just prefer some things).
It is all but impossible to 'accidentally' put your car in reverse instead of drive. Think about the number of times you hear a story about someone who did just that.
Point taken, except in a Volkswagen that puts reverse next to first (yeah, allegedly you have to push down and so it *should* be difficult, but I've ridden with enough people who make that mistake to be dubious).
I understand that the GPL allows some recoup of costs for development and distribution, but at all times the source must be available for free.
Actually, you only *need* to provide source to those who you provide binaries. So if your binaries require 20 dollars, you must provide the source to anyone who legitimately gets your binaries, but no more.
Of course, they can subsequently turn around and redistribute your source at will.
Cars: getting rid of stick shifts despite better fuel mileage and better safety
On mileage, CVT kinda throws a kink in the 'manuals are more efficient' argument. I'm not sure what's particularly safer about a stick shift, though I might buy more reliable on average. I think driving stick is more fun, personally.
I don't care *who* 'wants' it, Google is going along with it (and has been going along with it from even before movie studios were involved). The whole reality that one has to root/jailbreak your phone means the vendor is not being completely open.
Though less 'open', WebOS at least gives end users more sanctioned control over their device. You enter a well-documented code to enable the option to provide root shell and sideload applications. Too bad they have not seen success in the market, *but* I would encourage people seeking a device that gives them control to consider it a haven from iOS, Android, BalckBerry, and WP7 devices. I personally will only buy a phone that needs such BS as 'jailbreaking' when I simply have no option left. I don't care how 'easy' it is *unless* the manufacturer comes right out and officially says "here you go, we have no intent on restricting you in the future, have fun" (see http://developer.palm.com/blog/2011/05/10-reasons-for-geeks-to-love-hp-webos/ number 2). I don't want to be stuck in a fight with the company I gave money to for the duration of my ownership of it.
OpenMoko also is open *and* gives ultimate control, but unfortunately is a pretty impractical platform for a lot of the stuff people want to do with their handheld devices.
Funny, people can play this content on their personal computers. I too am dissatisfied with Linux support, but anyone claiming they don't support Linux it's due to DRM is full of it. So long as they let a Windows PC (which gives the users administrative access) play back the content, the argument is moot.
For example, say I want to start allowing port 22:
iptables -I INPUT -p tcp --dport 22 -j ACCEPT
That is not restarting firewall while users were using the system. I may have to do some juggling if I want the rule in the middle.
On a related note, I've always detested redhat firewall configuration for making more chains than needed for their straightforward configuration, making the rules appear far more complicated than they are.
Generally, linux desktop INPUT firewalls strike me as superfluous. That said, there is one use case, filtering out ports higher than 1024 from listening. This would mean any socket acting server-like would have to be explicitly blessed by someone with admin rights, which could mitigate certain types of trojan attacks.
What cracks me up is all these firewalling rules being automatically removed and inserted by installing the relevant application. For example install openssh and the firewall magically gets a rule to allow port 22. *This* is particularly asinine and is the sort of thing worthy of ridicule. If they can listen on a privileged port, they could change firewall rules, so filtering INPUT below 1024 for fear of malware is stupid (though it is a useful workaround for crappy apps without sufficient configurability to bind to specific interfaces).
Kind of, but with mouseover instead of click, which is not feasible for Unity (and unity does something weird if you are previewing one app and click on another running app).
Basically, gnome-shell makes it easy for mouseover to work because you've already entered a task-switching mode, so changing the preview windows based on current mouseover would be easier.
That's of course only one half, the window title search is still foreign.
Unity still has some quirky behavior, and frankly I'm just not a fan in general.
Gnome-shell is close, yet far away. It's more extensible seems like, which is promising. I just want two things:
-When I highlight an 'application icon' in the activities view, automatically show only the windows for that application in the window previews.
-Provide a means by which I can start typing and search window title bar contents (like KDE and Compiz Window Title Filter).
You have me sold on those two capabilities, which don't seem to exist. The gnome-shell-extensions have most of my other main requests covered.
You already are going outside the realm of supported things from RHEL. Might as well install perl yourself while you are at it.
Ok, guess I really meant:
"That means productivity apps like OpenOffice/etc will also work"
was inaccurate because it implied because of .Net and/or CLR that OpenOffice would work when in reality it's because it's FOSS and it'd be trivial to do.
OpenOffice is not written in Java (or .NET), so it won't work.
I would say a vast majority of Windows applications are *not* .NET (notably games, old-as-dirt product lines)
If a game costs 10 bucks new, not much of a secondary market. At least none that a Gamestop like company would have enough wiggle room to bother with. There might be a craigslist here and there, but no business in trade-in games. If you planned at doing $50 at your volume moves up by five-fold, revenue wise it's a wash, your game is more popular, and given the margins in software distribution your profit is probably the same too.
Similarly, the relative hassle/risk of pirating a game isn't appealing if you can just get legally licensed for a trivial sum.
The problem here is that generally means knowing the hash is just as good as knowing the password. This is the point most of the people employing that strategy miss. It may prevent an attacker from sitting at a keyboard using to blessed interface, but their own client modded to send the hash without even prompting for a password would be no better.
I'm with you *except* the last line.
I doubt I'll ever trust a service providers storage encryption rather than applying a local, independent layer of encryption they can't circumvent, *however*, it isn't entirely unreasonable to believe a cloud solution could include meaningful encryption that would preclude even their administrators from access, *even* in the dropbox case with files being shared. Granted, doing so and doing it conveniently means they probably have an exposure (I wager that the client software submits the password to server for authentication and therefore a modified server could capture password and use that to decrypt keys, which is the most straightforward thing to expect), but doing it privately is not impossible (e.g. shift auth to send down a prospective client the private key, protected by passpharse encryption, and the ability to answer a challenge serving as proof of password with the server retaining nor ever receiving at any time neither password or the key in the clear).
All that said, I'll continue to use local GPG keys on any data I host anyware that I remotely care about. If I need to share, then I'll employ the public keys of those I need to share with. Taking security into your own hands *as well* as any protections offered by the storage provider is always your best bet.
I suspect most all of the people that are amazon customers only vaguely know what's going on and won't bother to learn the detail on the hosting provider for the attackers systems.
I suspect the minority that are that inclined almost all know that in this specific scenario, Amazon was just a hosting provider and understand that means they aren't particularly responsible for what happened any more than AT&T would be responsible for a house downloading a video illegally.
Sure, there is probably a very small population that will stumble upon the facts and falsely presume Amazon is an evil company for cracking into Sony's stuff (as opposed to an evil company for other reasons). I have a feeling that change in revenue would be lost in the noise and small compared to any arbitrary boycott over seemingly small and/or inane things Amazon does on any given day.
I think you'd have to show that Amazon was *knowingly* selling the product afoul of your copyright (or patent if it's a machine or something) in order for Amazon to have some share of liability. Regardless of whether Amazon has any liability, you go after 'TheftCo' for wilfully violating your copyright.
This problem is hardly new as of electronic distribution, and there's zero reason to treat it any differently than if the problem happened in a brick and mortar bookstore.
Options: Beige
No other colors? Is Amazon being racist and rejecting other optons?
The authors can get their own hosting and handle their own storefront. Kindle, Apple, B&N, Kobo, etc have *no* lock-in where you have no choice but to buy from their store. An author can gleefully put up their own and sell (though if they want DRM on Kindle, then yes Amazon is the only way, but you sad yourself you didn't want DRM).
I happen to have a Kobo, but it would be no different if I had a Kindle. I have a vast minority of books purchased through Borders or Kobo, almost everything was gotten through other sources like Baen.
So if you are into selling Yaoi, then just make it clear it can't be bought through Amazon *and* provide an alternative instead of just whining. I'm sure your customers will notice the lack of their genre being available and do a web search and come across your explanation of the issue and the way to send money *directly* to you for purchase.
Maybe *you* don't know your password, but there is a good chance that the attackers can crack their copy of the hash and know your password. Resalting does precisely nothing because the danger is the attackers getting your password, and once they have that, any salt you apply will make no difference.