There are already test implementations. So, it's done. I sincerely believe the only reason it doesn't get further is because the "minds in charge" have come to the conclusion that the approach is not workable, for the reasons that I listed. I've read the discussions.
I'm aware that diffs are really hard. It was a pie-in-the-sky comment.
People always say: bittorrent can't work for debian because our files aren't large enough.
To that I say: Pish-tosh.
Sure, bittorrent is probably not the optimal protocol for such small files, but it will _work_ fine. The basic premise is this: large files take a long time to download, so over the course of the download, you will find peers and transfer data to them. Small files take a short time to download, so you will complete the download before getting started with bittorrent.
However, if you are downloading a large number of packages (as most downloads often do), then over the course of the entire download, a good number of peers who are downloading debian packages will be found. Many of them will be downloading the same packages that were updated since last week. In addition, there is no requirement that your client cease to participate as a peer once it has concluded downloading the packages. In a config-file I could set up my peer time, such as: continue providing data until 1:1 parity of download/upload has been achieved. Or I could even configure my download client to provide 4kbps of upload speed in perpetuity! Now I'm a debian mirror.
Sure getting this all going may not be a trivial endeavor, but it's certainly worth doing.
Now, if I could only think up a way to get package diffs so I don't have to download the entirety of xfree86 again when the packager fixes a typo in the readme file.
As I said elsewhere, #debian, the irc channel, is really bad/broken.
Debian the distribution is only somewhat bureaucratic and certainly committee based, but those things are both positives and detriments. As a whole, the project is not hostile, the related IRC channel is just problemed.
In general, try not to tie your irc experiences with a software project with the software project itself. Sometimes there is a strong overlap in membership, but often there isn't, and often nothing much in the way of development discussion occurs there. It *might* be fair to evaluate how focused that project is on providing user support, since if they were really excited about it they might fill the irc channel with helpful things and people, or create another forum obviating such a channel entirely.
#debian on freenode is one of the most abusive irc channels I've ever seen. It's definitely gone down the whole "hostile to ignorance" path further than I've encountered it anywhere else. It has in fact metstasized into not only hostility towards ignorance, nor just presumption of ignorance, but an attempt to prove ignorance when unwarranted in pretty much all cases, and then "righteously" dump hostility on that.
I'd love to know where the reasonable user support forum for Debian is, as I've been a Debian "testing" user for some 3-4 years now, and still have yet to find a good forum. Sure, there's the stable mailing list, but I don't run stable, and Debian's spam sheilding on its mailing lists leaves a lot to be desired.
Well it's possible to point to the better long term planning offered by the open source camp's development style that allows for such brokennesses during upgrades to be avoided.
Not sure if that was his rationale, but it is mine, for being unimpressed with the update, despite not being a windows user.
The point is: the vast mojority of python is highly readable and not explicitly or overly obfuscated in style. The natural style of the language is actually quite open and concise. He managed to find a single example of python which is hard to read DESPITE the nature of the language, and uses this to insist that having a language which encourages clarity is quixotic.
This is clearly stupid, because if you pull 99.9% of python code out of projects, off the internet, etc you will find that the syntax exudes this property of conciseness which python supports strongly.
Well clearly you don't actually know python. Python has scoping, it's just sane by default, so you don't worry about it. Explicit global is required if you want it.
Thus you don't need this explicit declaration, and making variables zeroed by default is also not needed.
According to BOTH the Heise article and the linked message: no.
Drives store the password data on the drive, not on the electronics, so the attack vector of controlling the electronics directly, while theoretically workable, will be difficult enough to be a waste of time. Apparently, again according to the article, data recovery specialiasts have figured out how to bypass the password security. It is possible they they use logic probes and the like, or it is possible they are just sending unxpected and poorly checked ATA commands. Certainly, if they can do it, you can do it.
So yes, it is _possible_ to retreive the data, but it is not clear how one would even start to go about it. It is likely that the cost of retreiveing the data yourself will be significantly higher than paying the specialists, and significantly higher than buying a new drive. It might _not_ be significantly higher than the cost of data loss.
Tools like cindent are a nice idea, although I've always found that they're unable to incorporate a sufficient amount of C formatting intelligence to match what a well trained editor and programmer staff can do. The C formatting at Wind River where we had an actual formatting standard that people followed (and emacs and vim and etc modes passed around to support it) was definitely superior to the layout I've gotten from autoformatting shops.
The brackets are more than just inconsistency, though. They're noise. If you regularize them by hook or crook, they're more ignorable noise, but they're still on the screen. Indentation flow removes the noise so you have more code per line without unnecessary noise.
The "languages that are not type checked" thing is a nice straw man, but it won't wash. Dynamically typed languages are type checked indeed, and in a way which allows for much more robust handling of problems. Statically typed languages allow you to catch a narrow subset of bugs at write time, at the cost of making it harder to catch all other categories of bugs over code bloat, and the cost of making it harder to reengineer your program when needs demand.
If by autoinitialize you mean that variables which haven't been assigned are magically existent and assigned to zero, then sorry python lacks this bug.
Regarding the object namespace/dictionary you can manipulate it directly if you've a good reason to see blah.__dict__. However, I wouldn't compare Python and Perl's object implementations to Python's detriment. Python's is useful, timesaving, and genearlly safe. Perl's is.. well.. sometimes useful.
Regarding in-place vs not, the semantics of the in-place sort operator is designed to force you to be aware of this fact. Notably, it returns None. As for the usability of this function, it's probably the biggest python usability wart I've ever encountered, which says a good deal.
Conversion functions are not casts! 45.3 is a number, "45.3" is a string. In the one case you are asking to change a float to an integer. I the other case you're asking to change a non-integer string to an integer. Yes it violates the principle of least surprise, but I wonder if this is a real-world problem. In a similar inconsistency with creating decimal/fixed numbers, a floating point number will generate an error, because it is fundamentally unsafe to do so. I wouldn't be surprised if there's a similar safety issue here, though obviously far less severe.
What syntax problems have you encountered at runtime in any python 2.x version? I've only seen such things in python 1.5 and prior and only regarding trivial issues.
And if as a programmer you are unable to see the benefits of smaller amounts of code which express the same logic just as well, then you probably shouldn't be coding at all.
Oh wait, I've just described 90% of all programmers. Hmm. No wonder software generally sucks.
I am baffled that the parent was modded up, given that it is clearly incorrect even according to the link listed.
To be clear, the link listed provides only one piece of information in addition to the heise article: drives come with a default master password, and it is possible to find out if it the default master password is still in place.
While handy information, it does not alleviate the security concerns. A locked drive is still inaccessable without the password. A malicious user or malware can change the master and user password and still render the drive a brick.
I mean, if I buy a product from a vendor who supports a politician who supports a war which kills people, I'm guilty of murder myself!
What I mean to say is, the poster suggested comlete equivalence. The wordpress developer has suggested he was not in complete awareness of the situation. If you don't believe him fine. However, even then,selling addspace and then being too lazy to take it down when it turns out to be spam is not the same wrong as pursuing and actively perpetrating spam. I was merely expressing my annoyance with the false equivalence.
Yes, false equivalences simplify thought, at the expense of accuracy.
Okay, that's basically what I thought. There is no good solution to this currently.
This is why I think that autopackage is premature, but that is clearly not the only view. If you can get all the people releasing unix libraries to properly support major minor etc that would be a huge blessing.
However, it seems sometimes it's really a matter of perspective. Sometimes a library is part of a project and has internally used "not published" apis. Then they change or remove these, but a distribution may package the library (which is used by other folks) seperately from the project binaries. So the project sees it as a minor update, but unix versioning rules would require a major number change, if strictly followed.
I guess I think that the work the distribution vendor does to coerce the software into a coherent state with a relative lack of kludging is inherently superior to distributing this work to software authors or distribution-independent packagers. If you can eliminate this disparity as you say by effectively pressing all unix developers into the de-facto unix interfaces policies, as well as other measures, that would be a huge win. And at that time I would think autopackage would be worth using.
Well, unless there's further changes. Like for example if the initial fix is decided to be an incomplete fix, so a new package is uploaded. The timer gets reset to 2 days. And then if it depends upon another package that isn't in testing, it could be delayed arbitrarily.
So I guess I would descibe it as "usually two days or more, where more is usually less than a week." Although sometimes I have seen security updates in less than 2 days. Maybe they waive policy for showstoppers.
I think you compiled with debugging on and are seeing the size of C++'s symbols, so it's really mostly disk usage that's balooned.
At least, I base this on the size of fluxbox, which has more features than blackbox and is a derivative along the same codebase. That windowmanager has a 1,182,852 byte image. I bet 'size' and 'ps' will tell you different things than 'ls'.
Re:What it really does.
on
Firefox Hacks
·
· Score: 1
Huh, I just get four imaged letters G N A A and then a little FLASH BLOCK click to play logo.
If I click-to-play it opens up a bunch of windows, but I can close them faster than it can open them, and can close the tab. Annoying, but it can be dealt with. Some of the javascript behavior was also disabled by privoxy, which scrubs my html for javascript annoyances.
Slashdot Mirror
There are already test implementations. So, it's done. I sincerely believe the only reason it doesn't get further is because the "minds in charge" have come to the conclusion that the approach is not workable, for the reasons that I listed. I've read the discussions.
I'm aware that diffs are really hard. It was a pie-in-the-sky comment.
Yeah I'd found debian planet, and when it was more active it was pretty good.
Search engines are tricky beasts. I HAVE tried and not found some of the ones you list. Thanks VERY MUCH for this list!
People always say: bittorrent can't work for debian because our files aren't large enough.
To that I say: Pish-tosh.
Sure, bittorrent is probably not the optimal protocol for such small files, but it will _work_ fine. The basic premise is this: large files take a long time to download, so over the course of the download, you will find peers and transfer data to them. Small files take a short time to download, so you will complete the download before getting started with bittorrent.
However, if you are downloading a large number of packages (as most downloads often do), then over the course of the entire download, a good number of peers who are downloading debian packages will be found. Many of them will be downloading the same packages that were updated since last week. In addition, there is no requirement that your client cease to participate as a peer once it has concluded downloading the packages. In a config-file I could set up my peer time, such as: continue providing data until 1:1 parity of download/upload has been achieved. Or I could even configure my download client to provide 4kbps of upload speed in perpetuity! Now I'm a debian mirror.
Sure getting this all going may not be a trivial endeavor, but it's certainly worth doing.
Now, if I could only think up a way to get package diffs so I don't have to download the entirety of xfree86 again when the packager fixes a typo in the readme file.
As I said elsewhere, #debian, the irc channel, is really bad/broken.
Debian the distribution is only somewhat bureaucratic and certainly committee based, but those things are both positives and detriments. As a whole, the project is not hostile, the related IRC channel is just problemed.
In general, try not to tie your irc experiences with a software project with the software project itself. Sometimes there is a strong overlap in membership, but often there isn't, and often nothing much in the way of development discussion occurs there. It *might* be fair to evaluate how focused that project is on providing user support, since if they were really excited about it they might fill the irc channel with helpful things and people, or create another forum obviating such a channel entirely.
#debian on freenode is one of the most abusive irc channels I've ever seen. It's definitely gone down the whole "hostile to ignorance" path further than I've encountered it anywhere else. It has in fact metstasized into not only hostility towards ignorance, nor just presumption of ignorance, but an attempt to prove ignorance when unwarranted in pretty much all cases, and then "righteously" dump hostility on that.
I'd love to know where the reasonable user support forum for Debian is, as I've been a Debian "testing" user for some 3-4 years now, and still have yet to find a good forum. Sure, there's the stable mailing list, but I don't run stable, and Debian's spam sheilding on its mailing lists leaves a lot to be desired.
Well it's possible to point to the better long term planning offered by the open source camp's development style that allows for such brokennesses during upgrades to be avoided.
Not sure if that was his rationale, but it is mine, for being unimpressed with the update, despite not being a windows user.
So your defense of the problems with flash is as follows:
- "Okay yes, flash is annoying but popups are worse."
- "Okay yes, flash things make annoying noises but I seem to remember java doing this too one time."
- "Okay you're right flash uses more CPU than most any other web thing."
This is a _defense_?
Now let's move on to more serious criticisms of flash.
Flash is a proprietary binary delivery method which when used a primary content delivery method defeats the promise of the web as an open medium.
Flash is generally not accessible to disabled people, defeating the utility of the web.
Flash is another attack vector to your computer given that it executes pseudocode in a poorly evaluated runtime.
The point is: the vast mojority of python is highly readable and not explicitly or overly obfuscated in style. The natural style of the language is actually quite open and concise. He managed to find a single example of python which is hard to read DESPITE the nature of the language, and uses this to insist that having a language which encourages clarity is quixotic.
This is clearly stupid, because if you pull 99.9% of python code out of projects, off the internet, etc you will find that the syntax exudes this property of conciseness which python supports strongly.
Was that clear enough for you?
Well clearly you don't actually know python. Python has scoping, it's just sane by default, so you don't worry about it. Explicit global is required if you want it.
Thus you don't need this explicit declaration, and making variables zeroed by default is also not needed.
According to BOTH the Heise article and the linked message: no.
Drives store the password data on the drive, not on the electronics, so the attack vector of controlling the electronics directly, while theoretically workable, will be difficult enough to be a waste of time. Apparently, again according to the article, data recovery specialiasts have figured out how to bypass the password security. It is possible they they use logic probes and the like, or it is possible they are just sending unxpected and poorly checked ATA commands. Certainly, if they can do it, you can do it.
So yes, it is _possible_ to retreive the data, but it is not clear how one would even start to go about it. It is likely that the cost of retreiveing the data yourself will be significantly higher than paying the specialists, and significantly higher than buying a new drive. It might _not_ be significantly higher than the cost of data loss.
Wow, you found a single counterexample! I guess that disproves the ENTIRE REST OF THE BODY OF CODE.
Tools like cindent are a nice idea, although I've always found that they're unable to incorporate a sufficient amount of C formatting intelligence to match what a well trained editor and programmer staff can do. The C formatting at Wind River where we had an actual formatting standard that people followed (and emacs and vim and etc modes passed around to support it) was definitely superior to the layout I've gotten from autoformatting shops.
The brackets are more than just inconsistency, though. They're noise. If you regularize them by hook or crook, they're more ignorable noise, but they're still on the screen. Indentation flow removes the noise so you have more code per line without unnecessary noise.
The "languages that are not type checked" thing is a nice straw man, but it won't wash. Dynamically typed languages are type checked indeed, and in a way which allows for much more robust handling of problems. Statically typed languages allow you to catch a narrow subset of bugs at write time, at the cost of making it harder to catch all other categories of bugs over code bloat, and the cost of making it harder to reengineer your program when needs demand.
If by autoinitialize you mean that variables which haven't been assigned are magically existent and assigned to zero, then sorry python lacks this bug.
.. well.. sometimes useful.
Regarding the object namespace/dictionary you can manipulate it directly if you've a good reason to see blah.__dict__. However, I wouldn't compare Python and Perl's object implementations to Python's detriment. Python's is useful, timesaving, and genearlly safe. Perl's is
Regarding in-place vs not, the semantics of the in-place sort operator is designed to force you to be aware of this fact. Notably, it returns None. As for the usability of this function, it's probably the biggest python usability wart I've ever encountered, which says a good deal.
Conversion functions are not casts! 45.3 is a number, "45.3" is a string. In the one case you are asking to change a float to an integer. I the other case you're asking to change a non-integer string to an integer. Yes it violates the principle of least surprise, but I wonder if this is a real-world problem. In a similar inconsistency with creating decimal/fixed numbers, a floating point number will generate an error, because it is fundamentally unsafe to do so. I wouldn't be surprised if there's a similar safety issue here, though obviously far less severe.
What syntax problems have you encountered at runtime in any python 2.x version? I've only seen such things in python 1.5 and prior and only regarding trivial issues.
Don't say "X is better". Say what specifically makes it seem better to you. Then your post develops meaning and worth.
Regarding Zope, it is hard "to get". It's convenient if you fit into its abilities neatly. I'm not yet sure if that's a good enough reason to use it.
And if as a programmer you are unable to see the benefits of smaller amounts of code which express the same logic just as well, then you probably shouldn't be coding at all.
Oh wait, I've just described 90% of all programmers. Hmm. No wonder software generally sucks.
I am baffled that the parent was modded up, given that it is clearly incorrect even according to the link listed.
To be clear, the link listed provides only one piece of information in addition to the heise article: drives come with a default master password, and it is possible to find out if it the default master password is still in place.
While handy information, it does not alleviate the security concerns. A locked drive is still inaccessable without the password. A malicious user or malware can change the master and user password and still render the drive a brick.
Yes indirection has no effect on anything.
I mean, if I buy a product from a vendor who supports a politician who supports a war which kills people, I'm guilty of murder myself!
What I mean to say is, the poster suggested comlete equivalence. The wordpress developer has suggested he was not in complete awareness of the situation. If you don't believe him fine. However, even then,selling addspace and then being too lazy to take it down when it turns out to be spam is not the same wrong as pursuing and actively perpetrating spam. I was merely expressing my annoyance with the false equivalence.
Yes, false equivalences simplify thought, at the expense of accuracy.
I guess you missed the part where the blog developer and the spammers are different agencies?
Okay, that's basically what I thought. There is no good solution to this currently.
This is why I think that autopackage is premature, but that is clearly not the only view. If you can get all the people releasing unix libraries to properly support major minor etc that would be a huge blessing.
However, it seems sometimes it's really a matter of perspective. Sometimes a library is part of a project and has internally used "not published" apis. Then they change or remove these, but a distribution may package the library (which is used by other folks) seperately from the project binaries. So the project sees it as a minor update, but unix versioning rules would require a major number change, if strictly followed.
I guess I think that the work the distribution vendor does to coerce the software into a coherent state with a relative lack of kludging is inherently superior to distributing this work to software authors or distribution-independent packagers. If you can eliminate this disparity as you say by effectively pressing all unix developers into the de-facto unix interfaces policies, as well as other measures, that would be a huge win. And at that time I would think autopackage would be worth using.
Well, unless there's further changes. Like for example if the initial fix is decided to be an incomplete fix, so a new package is uploaded. The timer gets reset to 2 days. And then if it depends upon another package that isn't in testing, it could be delayed arbitrarily.
So I guess I would descibe it as "usually two days or more, where more is usually less than a week." Although sometimes I have seen security updates in less than 2 days. Maybe they waive policy for showstoppers.
I think you compiled with debugging on and are seeing the size of C++'s symbols, so it's really mostly disk usage that's balooned.
At least, I base this on the size of fluxbox, which has more features than blackbox and is a derivative along the same codebase. That windowmanager has a 1,182,852 byte image. I bet 'size' and 'ps' will tell you different things than 'ls'.
Huh, I just get four imaged letters G N A A and then a little FLASH BLOCK click to play logo.
If I click-to-play it opens up a bunch of windows, but I can close them faster than it can open them, and can close the tab. Annoying, but it can be dealt with. Some of the javascript behavior was also disabled by privoxy, which scrubs my html for javascript annoyances.
No sound though.
FlashBlock: http://flashblock.mozdev.org/
Privoxy: http://www.privoxy.org/
I'm offtopic for answering a post?
Is thread-drift illegal on slashdot?
Is communication actively prevented?
I find it kind of hilarious how prostitution is illegal in Las Vegas yet somehow there are over 100 pages of "Escorts" in the phonebook.
I guess it's a very uhh.. rigidly enforced law.