If, however, even one undocumented instruction does not behave exactly as the real processor, or even one I/O channel is left unmunged, then there is a potential way the virtual environment could be detected.
Malware hosting doesn't have to be perfect and hide its presence in every possible way. It just has to hide in the ways that the market-leading malware detectors use. A malware author can just set up a test system and each time the detector finds a hit, track it down and emulate around it. As you suggest, the overhead could be VERY large if it tries to catch everything. It doesn't have to hit everything. Just the bits that matter.
Of course, eventually a new technique will be added to the detector, and it'll see the malware. Then the malware gets updated, and it is invisible again. Repeat forever.
And we're not even getting into the realm where the malware host detects and reacts to these particular tests, and just alters the code being run on the guest when it spots a process that is looking for it.
Oooh! Oooh! An exciting new paradigm. Is the world really ready for this exciting new paradigm yet. I bet it isn't!
Well, best of luck to them. My exciting new paradigm of sleeping in until midday every day hasn't caught on in the stoic and unchanging business world. They just haven't caught on to my forward and freethinking ways. But just you wait... my Slashdot story is coming soon!
Sorry, but the "Do it yourself," attitude is just bad. Even assuming it is directed at the extremely small segment of the population that has the level of programming knowledge required (usually it isn't) that then assumes that they have nothing better to do with their time. Sorry, not how it works.
On the other hand, there is no shortage of people complaining that a feature that they want is not present in a piece of software, yet expect someone else to write it for them. Or demanding "Linux isn't ready for the enterprise, now someone go develop features X, Y, and Z to appease me".
I think the angle is that they are a large company with many developers who are quite capable of implementing such a thing, should they wish. I viewed QuantumG's comment in a much more positive light- as in "because the source is open, you can add whatever new features you want!" rather than "nick off, do it yourself". I found the comment neither arrogant, nor elitist, nor representative of such.
There's one detail where it seems I disagree with you. Where you say "they return the printout as a spoiled ballot" I get the impression that you mean that they give the spoiled ballot to some poll worker. But if that's what you mean, then that would break voting secrecy. Instead you just tear it apart and put it in a wastebasket inside the voting booth. It's best if this wastebasket is a locked box with a slit, so that nobody can see the interior. At the end of the day nobody knows who threw away what.
I think it is more the matter of me not understanding how spoiled ballots are currently handled rather than us disagreeing here. I know there is a process in place here (Australia) for example, by which you somehow return a ballot which you have accidentally spoiled (ie. messed up) and get a new one. I haven't actually spoiled a ballot thus far, so I don't know what the process is. I presume the folded ballot is dropped into a spoiled ballot box, and they give you a fresh one.
A similar thing could be done with electronically-assisted voting- much like the voting box, you deposit your printout into a spoiled ballot box, and then are allowed back to redo your vote. All that needs to be seen is that you put exactly one folded bit of paper into this box (they don't need to see what is on it) before you can go back again. Of course it would be in a different direction than the valid vote box, because you don't want people coming back to vote again after putting a ballot in the valid voting box.;)
One thing I find unusual in threads on electronic voting is how people seem to suggest that they need a receipt. A receipt is, of course, for the reasons you state a very bad idea. Conversely, people don't ask for a receipt when they vote by paper. In fact, can you imagine the reaction if you asked an election official for permission to photocopy your vote before you cast it?
Of course, the reason may be the (very true) feeling that there is much more potential for misuse of electronic voting machines. It still doesn't justify the loss of anonymity.
I believe electronic voting machines should be pushed as an aid to the voting process, rather than a replacement. Get a machine with a nice, simple GUI. If the process is preferential rather than tick-in-the-box, let them drag around pictures of the candidates on the screen. When it is all done, let them hit a big green "Cast Vote" button. Out comes a printout with all of the ticks, crosses, and numbers in the right place. The voter then looks at their printout, and if they're happy, they drop it in the voting box, just like with a paper one. If they mess up, they return the printout as a spoiled ballot, and go back and do it again. You have a separate box and forms for people who want to fill it out by hand. At election close, you hand-count the hand-filled ones. You then split the printouts into batches. You scan each batch quickly (since the format is very consistent with printouts) and you have some preliminary results. You then handcount as many batches are needed (probably all of them) and use the scanned totals as a check. If they diverge too much, you get in triple the number of people and hand-count them again.
That way, the machines help- but not replace- the whole election process.
(As previously posted into the wrong thread by accident- long day)
I don't know why but this shit seems really hard to get right. Electronic stock trading, bank transactions, military systems etc - no problem. Electronic voting - disaster every time.
Because anonymity plus accountability is really difficult.
In other systems you have nice trails that you can follow in the case of fraud.
In voting you need to ensure voter anonymity and it makes it that much harder to verify results. Add in political corruption and pressure from moneyed interests and it becomes a very hard problem indeed.
How on earth did you manage to reply in the wrong thread?
Long day. Saw comment, went back to main page, logged in, found comment, probably clicked on the wrong link, wrote reply, previewed, posted, realised mistake after seeing your reply, felt like idiot.
I don't know why but this shit seems really hard to get right. Electronic stock trading, bank transactions, military systems etc - no problem. Electronic voting - disaster every time.
Because anonymity plus accountability is really difficult.
In other systems you have nice trails that you can follow in the case of fraud.
In voting you need to ensure voter anonymity and it makes it that much harder to verify results. Add in political corruption and pressure from moneyed interests and it becomes a very hard problem indeed.
What's wrong with this picture? The problem is that most Linux people have a cooks-first mentality, and when a regular diner comes along with a question or any comment except for extreme praise, the standard answer translates into "Why haven't you read the cookbook yet? The answer is right there." Well, the reason they didn't read the cookbook is because they just want to eat a tasty Linux sandwich, not to become a master chef.
There are rude and arrogant idiots waving the flags of every operating system. For every "RTFM n00b" comment made relating to a Linux distro there is a "well my Windows PC never crashes because *I* know how to configure it properly" relating to a Windows system. For every inexperienced user trying to maintain his new Linux box who is berated, there is an inexperienced Windows user who is patronised because he doesn't know what to click and where.
The perception that rude and arrogant computer users only belittle the inexperienced on Linux is a false one. There's no shortage of rude, arrogant and patronising people, no matter what OS you are running.
Unlike the Linux competition between distros, there is no real competition driving innovation within Microsoft Windows. They sort of notice it, but why bother? They'll continue squeezing blood out of the turnips forever even if they fire *ALL* of their development programmers and just retain a skeleton staff of maintenance programmers.
And I just wanted to add that I think you're dead right here. I think they could get away with doing this, for quite some time, if they so chose.
How many other apps do you know that replace half of the system libraries?
Try an install of the Visual Studio.NET family. Can't remember if it messes with system files but it messes around with Office files, even if Office isn't around. You then need to use Office patches to update them. It's insane.
To respond to you and parent, keep in mind that the court of public opinion is very strong.
Most people barely understand who Microsoft is, or what an operating system is anyway. Even less are familiar with Microsoft's past actions. The Microsoft name is mud in a majority of tech circles but it is important to note that such circles are an absolute minority of the population. Basically: Not many people know, care, or know why they should care.
If you asked two dozen random people (ie. not techie friends) who SCO are (probably a good example of a company spitting directly in public opinion), how many do you think would know? How many would roughly understand the significance of their claims?
How about if you asked them about the GPL. How many know about it? How many could say (roughly) what it does?
Imagine if MS went for a straight outright kill on the GPL through some proxy, I can imagine some severe techie outrage. I'd be furious, personally. But can you see the bulk of people noticing, caring, or even understanding why they should care?
Anyway, my point is that they probably are not overly fearful of the court of public opinion, and they are certainly good at downplaying the significance of their actions in any case.
...a draconian and insane copyright situation in the US.... is because the US Congress is largely bought and paid for by the highest bidder. So you have things like the DMCA and 100+ year copyright terms.
We may disagree on other issues, but we've got common ground on these at least.
My point, of course, is what this kill-switch can be used for in the future. It is the recurring theme of my posts. You state that playing content with the kill-switch off won't cause problems. I think it is pretty clear from my posts that I know this- or at the least the impact isn't something I am discussing at present. My question is why a select few people try to write the issue off as unimportant, when it is very clear what can be done with the misfeature in the future.
Is the position I am suggesting- that there may be cause for concern, so unpalatable that people need to resort to (borderline) ad hominem and misdirection to dilute my point? Who would find a plea for awareness and caution to such a thing abhorrent? Certainly an interesting question.
No doubt I'll be posting again in a similar thread in the future discussing similar things. I'll catch you there!
I didn't. I had suspected that such things were in the works but didn't realise they were already in play until a few weeks ago. A great many people do not know about it either. Keeping people in the dark appears to be quite deliberate.
The worst think that could happen is they piss me off with onerous DRM and I don't buy their shit content. Big deal.
I suspect you know this already and are deliberately not mentioning it, so I'll respond for the sake of anyone who is still reading:
How will you know, before purchase, that whatever DRM is in place will deliberately degrade the output quality when you get it home?
And to preempt the reply: "I'll just return it as defective":
Do you honestly expect people to repeatedly return merchandise when the majority of content providers decide that they all want to turn the kill-switch on in their content? Go back to the store and argue with the the sales people each time that it doesn't work on your PC? Perhaps repeatedly issue credit card chargebacks? Your credit provider will love this. What if you've ordered it from overseas? Now you're paying a penalty each time you return something broken.
Anyway, you seem fairly set in your beliefs and I won't be the one to change your mind. If what I've said thus far hasn't stuck it is unlikely that we'll find a common ground. I just hope that enough people become aware of what is going on to ensure that we don't have yet another customer-hostile restriction forced upon us. I am not optimistic.
How very interesting. You consider the stealthy inclusion of a quality kill-switch that can be arbitrarily enabled in the future on "unapproved" hardware to be a triviality? Personally, I find it concerning, and a point a supposed tech writer should not be dismissive of.
In other words Vista will display HD images but only in un-DRM mode, and if you try to pay a movie that you have bought and paid for but which has the flag set for 'trusted output path' or whatever they call it, Vista will refuse to display it. Which is, I think, the point Peter Gutmann was trying to make.
And the fact that Bott subsequently tries to dismiss the whole thing as a triviality, even in the face of the obvious future use of this misfeature, really does call his objectivity and credibility into question.
- Somebody PLEASE develop a consistent library and API with minimal requirements that can interface with a whole bunch of windowing environments- including GNOME and KDE at a minimum. It should load the specific windowing interfaces dynamically so that using this common library adds no further dependencies to an application that uses it. From this interface I'd want to see fully-customisable keybindings, macros, and GUI controls of various sorts, an ability to hook to interesting events (eg. about to suspend, woken up, user logged out of GUI), info about screen layouts, access to user preferences regarding these applications (window positioning for particular apps, etc), and some assistance in loading and restoring state.
xlib?
Haha.;)
But yes, something like that- at least in the sense it is a common base that the various windowing environments use. With emphasis, of course, being on that it is something that they all want to use.
- I have been awfully tempted to attempt this myself but I know it would be far too large a project for a single person. I'd never finish it on my own, and I'm not interested in the politics it would take to get traction on such a thing.
Start the project, show the benefits from what you have, and you might find interested people joining you.
Reasons why I won't be doing this covered in my original post. It's still nice to dream though.
[Just quickly, in response to the first two paragraphs, I think that's pretty much what/proc is for. It makes a lot of interfacing with the kernel simple.]
Very true, and no doubt quite useful.
It's going to be hard to elaborate on the sort of things I mean without sounding like a fool since my kernel-level knowledge is exceptionally weak and I am do doubt surrounded by people who forget more kernel-level details in a day than I'll know in my lifetime. Let's just say it would be nice to have an easy "in" for this sort of thing. Basically it would be nice if I could easily defer certain kernel features (say file security) to a separate user-space daemon that I could play around with fairly safely. There are also some things that are more suited to userspace- say anything involving complex parsing or structure building. It'd be nice to have plenty of hooks into the kernel to use such things.
As for your library for working with a bunch of environments, I had the contrapositive idea a while back: hear me out. A tool to theme Qt, GTK, and your Window Manager as similar as possible. That way, it wouldn't matter what programmers developed for, because it would all look the same on your system. That's a lot easier than trying to unify different widget sets and the like with an extra interface.
You'll probably find a fair few {KDE,GNOME} {users,developers} who are quite hostile at making their environment similar to {GNOME,KDE}. But I think if you could somehow develop the sort of unification tookit that would preserve their distinctivenes whilst allowing you to blend the best of both featuresets you'd leave everyone happy.
+kudos on the configurable controls, key bindings, macros and scripting for the GUI interface- I think we will head in that direction soon enough. Maybe you should write some small example patches for Qt or GTK?
The thing I'm talking about is more a complete system than small patches for widget sets. Until the groundwork of what I've described was built up I imagine the maintainers for each of them would look at the patches and wonder what it gains them... then realise it is very little, and drop them.:( However, if it gained them hooks into a whole lot of the features I described previously, I can see developers jumping all over them. I guess it's all about making something that makes window system developers happy, application developers happy, and provide features that the users of the apps want. Unfortuantely that means a lot more work upfront, and then getting developers excited enough to get behind it as well. To be honest it's something I'd love to play around with if I had the time- which of course I don't.
Bring down the barriers relating to kernel development. We're talking documentation, convenience interfaces between the kernel-level stuff and userland, so forth. Spend a bit of time making kernel modules VERY feature-laden. Make them very easy to play with and ensure there are plenty of user-space tools to help you out. I've mucked around with a lot of stuff and have been developing software for a couple of decades now, but the Linux kernel STILL scares me.
Layer a set of version-consistent APIs above some of the low-level kernel stuff so driver developers don't have to target as many different setups or rely on a compiler being on the system to do their magic. I know this is a very unpopular idea in the kernel circles, but I think it would be very beneficial.
Of course I'm going to get ripped apart on the prior two paragraphs from people who know much more than me in those areas, so let's just say that these are just my thoughts from an external perspective.
Now moving on...
Operating system?
Somebody PLEASE develop a consistent library and API with minimal requirements that can interface with a whole bunch of windowing environments- including GNOME and KDE at a minimum. It should load the specific windowing interfaces dynamically so that using this common library adds no further dependencies to an application that uses it. From this interface I'd want to see fully-customisable keybindings, macros, and GUI controls of various sorts, an ability to hook to interesting events (eg. about to suspend, woken up, user logged out of GUI), info about screen layouts, access to user preferences regarding these applications (window positioning for particular apps, etc), and some assistance in loading and restoring state.
The library could then be taken and developed so that it is so appealing to developers they really have no reason not to use it, and the interfaces appealing to enough of the windowing environment developers so that they want to integrate it as well. It'd have a very liberal license (say BSD) applied to it to keep people using it.
Along with the library you'd have a set of tools that build on a whole bunch of environments (say: GNOME, KDE, and something that uses straight X). They would be used to set up all of the customisation that users could possibly want. The interfaces would have a simple mode for users that like very basic interfaces (actually to keep the people who claim that people want this happy), and a simple checkbox to enable "expert" mode that displays everything in obscene detail. The tools would have a sharing license (say GPL) to keep people pitching in their changes.
And then you'd need a whole bunch of people to promote it to make sure people know about it.
Imagine being able to fully configure all of your graphical apps to act how YOU want, drop in extra controls, keyboard shortcuts, trivially add in macros for remote app control, so forth- all without the developers of those applications needing to worry about it themselves. Why? The library handles it for them. The GNOME people and the KDE people can keep going about things their own way as well, and they'll keep making their own advances too. But they'll both be saved reinventing the same wheel in this common ground, whilst still having full control to take their projects to where they want to go.
I have been awfully tempted to attempt this myself but I know it would be far too large a project for a single person. I'd never finish it on my own, and I'm not interested in the politics it would take to get traction on such a thing.
Slashdot Mirror
If, however, even one undocumented instruction does not behave exactly as the real processor, or even one I/O channel is left unmunged, then there is a potential way the virtual environment could be detected.
Malware hosting doesn't have to be perfect and hide its presence in every possible way. It just has to hide in the ways that the market-leading malware detectors use. A malware author can just set up a test system and each time the detector finds a hit, track it down and emulate around it. As you suggest, the overhead could be VERY large if it tries to catch everything. It doesn't have to hit everything. Just the bits that matter.
Of course, eventually a new technique will be added to the detector, and it'll see the malware. Then the malware gets updated, and it is invisible again. Repeat forever.
And we're not even getting into the realm where the malware host detects and reacts to these particular tests, and just alters the code being run on the guest when it spots a process that is looking for it.
Damn. What are the odds that the Olin College grads got mod points on the same day that the story went live...
Courage always helped me build the best bridges!
;)
It certainly allows you to cross the worst ones.
Oooh! Oooh! An exciting new paradigm. Is the world really ready for this exciting new paradigm yet. I bet it isn't!
Well, best of luck to them. My exciting new paradigm of sleeping in until midday every day hasn't caught on in the stoic and unchanging business world. They just haven't caught on to my forward and freethinking ways. But just you wait... my Slashdot story is coming soon!
I would LOVE to torture to death every single person who thinks they are clever by using a regexp replace in an internet post.
s/you/just bitter/g
Sorry, but the "Do it yourself," attitude is just bad. Even assuming it is directed at the extremely small segment of the population that has the level of programming knowledge required (usually it isn't) that then assumes that they have nothing better to do with their time. Sorry, not how it works.
On the other hand, there is no shortage of people complaining that a feature that they want is not present in a piece of software, yet expect someone else to write it for them. Or demanding "Linux isn't ready for the enterprise, now someone go develop features X, Y, and Z to appease me".
I think the angle is that they are a large company with many developers who are quite capable of implementing such a thing, should they wish. I viewed QuantumG's comment in a much more positive light- as in "because the source is open, you can add whatever new features you want!" rather than "nick off, do it yourself". I found the comment neither arrogant, nor elitist, nor representative of such.
If I could get ONE wish fulfilled would be for OS scheduling to focus on processes, and not threads
Yeah, a lot of us feel the same way about the fancy-dressing guys that work over in the sales office.
If there ever was a case for a "+1 Brilliant" moderation option or a final moderation of (Score:6 Funny), this is it.
There's one detail where it seems I disagree with you. Where you say "they return the printout as a spoiled ballot" I get the impression that you mean that they give the spoiled ballot to some poll worker. But if that's what you mean, then that would break voting secrecy. Instead you just tear it apart and put it in a wastebasket inside the voting booth. It's best if this wastebasket is a locked box with a slit, so that nobody can see the interior. At the end of the day nobody knows who threw away what.
;)
I think it is more the matter of me not understanding how spoiled ballots are currently handled rather than us disagreeing here. I know there is a process in place here (Australia) for example, by which you somehow return a ballot which you have accidentally spoiled (ie. messed up) and get a new one. I haven't actually spoiled a ballot thus far, so I don't know what the process is. I presume the folded ballot is dropped into a spoiled ballot box, and they give you a fresh one.
A similar thing could be done with electronically-assisted voting- much like the voting box, you deposit your printout into a spoiled ballot box, and then are allowed back to redo your vote. All that needs to be seen is that you put exactly one folded bit of paper into this box (they don't need to see what is on it) before you can go back again. Of course it would be in a different direction than the valid vote box, because you don't want people coming back to vote again after putting a ballot in the valid voting box.
One thing I find unusual in threads on electronic voting is how people seem to suggest that they need a receipt. A receipt is, of course, for the reasons you state a very bad idea. Conversely, people don't ask for a receipt when they vote by paper. In fact, can you imagine the reaction if you asked an election official for permission to photocopy your vote before you cast it?
Of course, the reason may be the (very true) feeling that there is much more potential for misuse of electronic voting machines. It still doesn't justify the loss of anonymity.
I believe electronic voting machines should be pushed as an aid to the voting process, rather than a replacement. Get a machine with a nice, simple GUI. If the process is preferential rather than tick-in-the-box, let them drag around pictures of the candidates on the screen. When it is all done, let them hit a big green "Cast Vote" button. Out comes a printout with all of the ticks, crosses, and numbers in the right place. The voter then looks at their printout, and if they're happy, they drop it in the voting box, just like with a paper one. If they mess up, they return the printout as a spoiled ballot, and go back and do it again. You have a separate box and forms for people who want to fill it out by hand. At election close, you hand-count the hand-filled ones. You then split the printouts into batches. You scan each batch quickly (since the format is very consistent with printouts) and you have some preliminary results. You then handcount as many batches are needed (probably all of them) and use the scanned totals as a check. If they diverge too much, you get in triple the number of people and hand-count them again.
That way, the machines help- but not replace- the whole election process.
(As previously posted into the wrong thread by accident- long day)
I don't know why but this shit seems really hard to get right. Electronic stock trading, bank transactions, military systems etc - no problem. Electronic voting - disaster every time.
Because anonymity plus accountability is really difficult.
In other systems you have nice trails that you can follow in the case of fraud.
In voting you need to ensure voter anonymity and it makes it that much harder to verify results. Add in political corruption and pressure from moneyed interests and it becomes a very hard problem indeed.
How on earth did you manage to reply in the wrong thread?
Long day. Saw comment, went back to main page, logged in, found comment, probably clicked on the wrong link, wrote reply, previewed, posted, realised mistake after seeing your reply, felt like idiot.
I don't know why but this shit seems really hard to get right. Electronic stock trading, bank transactions, military systems etc - no problem. Electronic voting - disaster every time.
Because anonymity plus accountability is really difficult.
In other systems you have nice trails that you can follow in the case of fraud.
In voting you need to ensure voter anonymity and it makes it that much harder to verify results. Add in political corruption and pressure from moneyed interests and it becomes a very hard problem indeed.
What's wrong with this picture? The problem is that most Linux people have a cooks-first mentality, and when a regular diner comes along with a question or any comment except for extreme praise, the standard answer translates into "Why haven't you read the cookbook yet? The answer is right there." Well, the reason they didn't read the cookbook is because they just want to eat a tasty Linux sandwich, not to become a master chef.
There are rude and arrogant idiots waving the flags of every operating system. For every "RTFM n00b" comment made relating to a Linux distro there is a "well my Windows PC never crashes because *I* know how to configure it properly" relating to a Windows system. For every inexperienced user trying to maintain his new Linux box who is berated, there is an inexperienced Windows user who is patronised because he doesn't know what to click and where.
The perception that rude and arrogant computer users only belittle the inexperienced on Linux is a false one. There's no shortage of rude, arrogant and patronising people, no matter what OS you are running.
Unlike the Linux competition between distros, there is no real competition driving innovation within Microsoft Windows. They sort of notice it, but why bother? They'll continue squeezing blood out of the turnips forever even if they fire *ALL* of their development programmers and just retain a skeleton staff of maintenance programmers.
And I just wanted to add that I think you're dead right here. I think they could get away with doing this, for quite some time, if they so chose.
How many other apps do you know that replace half of the system libraries?
.NET family. Can't remember if it messes with system files but it messes around with Office files, even if Office isn't around. You then need to use Office patches to update them. It's insane.
Try an install of the Visual Studio
Well, I'm off to deposit $655.35 less my current balance into my bank account.
1 2 3 4 5 5 6 7 8 9
;)
But I think the Count can manage to count to six without stuttering.
Geez, way to go. Give 'em a chance to fix their current problems before you start finding new ones.
To respond to you and parent, keep in mind that the court of public opinion is very strong.
Most people barely understand who Microsoft is, or what an operating system is anyway. Even less are familiar with Microsoft's past actions. The Microsoft name is mud in a majority of tech circles but it is important to note that such circles are an absolute minority of the population. Basically: Not many people know, care, or know why they should care.
If you asked two dozen random people (ie. not techie friends) who SCO are (probably a good example of a company spitting directly in public opinion), how many do you think would know? How many would roughly understand the significance of their claims?
How about if you asked them about the GPL. How many know about it? How many could say (roughly) what it does?
Imagine if MS went for a straight outright kill on the GPL through some proxy, I can imagine some severe techie outrage. I'd be furious, personally. But can you see the bulk of people noticing, caring, or even understanding why they should care?
Anyway, my point is that they probably are not overly fearful of the court of public opinion, and they are certainly good at downplaying the significance of their actions in any case.
...a draconian and insane copyright situation in the US. ... is because the US Congress is largely bought and paid for by the highest bidder. So you have things like the DMCA and 100+ year copyright terms.
We may disagree on other issues, but we've got common ground on these at least.
My point, of course, is what this kill-switch can be used for in the future. It is the recurring theme of my posts. You state that playing content with the kill-switch off won't cause problems. I think it is pretty clear from my posts that I know this- or at the least the impact isn't something I am discussing at present. My question is why a select few people try to write the issue off as unimportant, when it is very clear what can be done with the misfeature in the future.
Is the position I am suggesting- that there may be cause for concern, so unpalatable that people need to resort to (borderline) ad hominem and misdirection to dilute my point? Who would find a plea for awareness and caution to such a thing abhorrent? Certainly an interesting question.
No doubt I'll be posting again in a similar thread in the future discussing similar things. I'll catch you there!
You didn't know about this ages ago?
I didn't. I had suspected that such things were in the works but didn't realise they were already in play until a few weeks ago. A great many people do not know about it either. Keeping people in the dark appears to be quite deliberate.
The worst think that could happen is they piss me off with onerous DRM and I don't buy their shit content. Big deal.
I suspect you know this already and are deliberately not mentioning it, so I'll respond for the sake of anyone who is still reading:
How will you know, before purchase, that whatever DRM is in place will deliberately degrade the output quality when you get it home?
And to preempt the reply: "I'll just return it as defective":
Do you honestly expect people to repeatedly return merchandise when the majority of content providers decide that they all want to turn the kill-switch on in their content? Go back to the store and argue with the the sales people each time that it doesn't work on your PC? Perhaps repeatedly issue credit card chargebacks? Your credit provider will love this. What if you've ordered it from overseas? Now you're paying a penalty each time you return something broken.
Anyway, you seem fairly set in your beliefs and I won't be the one to change your mind. If what I've said thus far hasn't stuck it is unlikely that we'll find a common ground. I just hope that enough people become aware of what is going on to ensure that we don't have yet another customer-hostile restriction forced upon us. I am not optimistic.
It is a triviality.
How very interesting. You consider the stealthy inclusion of a quality kill-switch that can be arbitrarily enabled in the future on "unapproved" hardware to be a triviality? Personally, I find it concerning, and a point a supposed tech writer should not be dismissive of.
In other words Vista will display HD images but only in un-DRM mode, and if you try to pay a movie that you have bought and paid for but which has the flag set for 'trusted output path' or whatever they call it, Vista will refuse to display it. Which is, I think, the point Peter Gutmann was trying to make.
And the fact that Bott subsequently tries to dismiss the whole thing as a triviality, even in the face of the obvious future use of this misfeature, really does call his objectivity and credibility into question.
- Somebody PLEASE develop a consistent library and API with minimal requirements that can interface with a whole bunch of windowing environments- including GNOME and KDE at a minimum. It should load the specific windowing interfaces dynamically so that using this common library adds no further dependencies to an application that uses it. From this interface I'd want to see fully-customisable keybindings, macros, and GUI controls of various sorts, an ability to hook to interesting events (eg. about to suspend, woken up, user logged out of GUI), info about screen layouts, access to user preferences regarding these applications (window positioning for particular apps, etc), and some assistance in loading and restoring state.
;)
xlib?
Haha.
But yes, something like that- at least in the sense it is a common base that the various windowing environments use. With emphasis, of course, being on that it is something that they all want to use.
- I have been awfully tempted to attempt this myself but I know it would be far too large a project for a single person. I'd never finish it on my own, and I'm not interested in the politics it would take to get traction on such a thing.
Start the project, show the benefits from what you have, and you might find interested people joining you.
Reasons why I won't be doing this covered in my original post. It's still nice to dream though.
[Just quickly, in response to the first two paragraphs, I think that's pretty much what /proc is for. It makes a lot of interfacing with the kernel simple.]
:( However, if it gained them hooks into a whole lot of the features I described previously, I can see developers jumping all over them. I guess it's all about making something that makes window system developers happy, application developers happy, and provide features that the users of the apps want. Unfortuantely that means a lot more work upfront, and then getting developers excited enough to get behind it as well. To be honest it's something I'd love to play around with if I had the time- which of course I don't.
Very true, and no doubt quite useful.
It's going to be hard to elaborate on the sort of things I mean without sounding like a fool since my kernel-level knowledge is exceptionally weak and I am do doubt surrounded by people who forget more kernel-level details in a day than I'll know in my lifetime. Let's just say it would be nice to have an easy "in" for this sort of thing. Basically it would be nice if I could easily defer certain kernel features (say file security) to a separate user-space daemon that I could play around with fairly safely. There are also some things that are more suited to userspace- say anything involving complex parsing or structure building. It'd be nice to have plenty of hooks into the kernel to use such things.
As for your library for working with a bunch of environments, I had the contrapositive idea a while back: hear me out. A tool to theme Qt, GTK, and your Window Manager as similar as possible. That way, it wouldn't matter what programmers developed for, because it would all look the same on your system. That's a lot easier than trying to unify different widget sets and the like with an extra interface.
You'll probably find a fair few {KDE,GNOME} {users,developers} who are quite hostile at making their environment similar to {GNOME,KDE}. But I think if you could somehow develop the sort of unification tookit that would preserve their distinctivenes whilst allowing you to blend the best of both featuresets you'd leave everyone happy.
+kudos on the configurable controls, key bindings, macros and scripting for the GUI interface- I think we will head in that direction soon enough. Maybe you should write some small example patches for Qt or GTK?
The thing I'm talking about is more a complete system than small patches for widget sets. Until the groundwork of what I've described was built up I imagine the maintainers for each of them would look at the patches and wonder what it gains them... then realise it is very little, and drop them.
Kernel?
Bring down the barriers relating to kernel development. We're talking documentation, convenience interfaces between the kernel-level stuff and userland, so forth. Spend a bit of time making kernel modules VERY feature-laden. Make them very easy to play with and ensure there are plenty of user-space tools to help you out. I've mucked around with a lot of stuff and have been developing software for a couple of decades now, but the Linux kernel STILL scares me.
Layer a set of version-consistent APIs above some of the low-level kernel stuff so driver developers don't have to target as many different setups or rely on a compiler being on the system to do their magic. I know this is a very unpopular idea in the kernel circles, but I think it would be very beneficial.
Of course I'm going to get ripped apart on the prior two paragraphs from people who know much more than me in those areas, so let's just say that these are just my thoughts from an external perspective.
Now moving on...
Operating system?
Somebody PLEASE develop a consistent library and API with minimal requirements that can interface with a whole bunch of windowing environments- including GNOME and KDE at a minimum. It should load the specific windowing interfaces dynamically so that using this common library adds no further dependencies to an application that uses it. From this interface I'd want to see fully-customisable keybindings, macros, and GUI controls of various sorts, an ability to hook to interesting events (eg. about to suspend, woken up, user logged out of GUI), info about screen layouts, access to user preferences regarding these applications (window positioning for particular apps, etc), and some assistance in loading and restoring state.
The library could then be taken and developed so that it is so appealing to developers they really have no reason not to use it, and the interfaces appealing to enough of the windowing environment developers so that they want to integrate it as well. It'd have a very liberal license (say BSD) applied to it to keep people using it.
Along with the library you'd have a set of tools that build on a whole bunch of environments (say: GNOME, KDE, and something that uses straight X). They would be used to set up all of the customisation that users could possibly want. The interfaces would have a simple mode for users that like very basic interfaces (actually to keep the people who claim that people want this happy), and a simple checkbox to enable "expert" mode that displays everything in obscene detail. The tools would have a sharing license (say GPL) to keep people pitching in their changes.
And then you'd need a whole bunch of people to promote it to make sure people know about it.
Imagine being able to fully configure all of your graphical apps to act how YOU want, drop in extra controls, keyboard shortcuts, trivially add in macros for remote app control, so forth- all without the developers of those applications needing to worry about it themselves. Why? The library handles it for them. The GNOME people and the KDE people can keep going about things their own way as well, and they'll keep making their own advances too. But they'll both be saved reinventing the same wheel in this common ground, whilst still having full control to take their projects to where they want to go.
I have been awfully tempted to attempt this myself but I know it would be far too large a project for a single person. I'd never finish it on my own, and I'm not interested in the politics it would take to get traction on such a thing.
But I'd love to see it.