There's more than just "a lot wrong" in my book. As soon as you wrap a program up with some obligation for the user (installer) to actaully _do_ something particular (read and affirm an agreement), you are restricting the user's freedom to simply to do what he wants with the code (for himself), i.e. going against the OSI way of thinking.
I don't think click-through and OSI mix, and I'm glad the decision was made that way.
" How can you trust a package to check it's own MD5 checksum? "
You don't. The checking must be done prior to doing _anything_ with the not-yet-trusted package. It's a md5 of the.gz, so you don't even unzip it before you do the checking.
"The installer" refers to a trusted program that may download, check, unpack, compile, install, and configure a new package.
It does not refer to the new package's own 'make install' behaviour.
Almost all the major distributions (of various Un*ces) have some kind of package installer nowadays.
Not true. It _does_ affect the behaviour if the constructors or destructor have side effects (such as static instance counters, or cout< However, the standard explicitly indicates that this optimisation and change in behaviour is permitted, and therefore that you mustn't rely on every apparent constructor actually being called.
The reason the change in behaviour was permitted by the standards body is because it decided that the potential for optimisation would be worth it.
I too read it as "full disclosure unless bound by prior contract", which I interprested as what you say. It's not well worded, but it's not actually wrong.
THL.
Re:It was bound to happen sooner or later.
on
RIAA Smacked by DoS
·
· Score: 2, Interesting
Agreed.
I reckon that it would be interesteing if the P2P networks were to have a "cry for help" facility, such that if a peer thought it was being dDOSed by the RIAA or whomever else, it would summon help from other peers. Hmmm, currently the only 'help' I can imagine is a return dDOS against the RIAA.
Welcome to the MAdD scenario, Mutually Assured distributed Destruction!
Of course everyone apart from those who paid off the politicians would probably end up in jail - remember to leave your computers switched on, though, as they arrest you.
{{{ RSA can be broken by factoring a large number, and a 128-bit number poses little challenge for even the Sieve of Eratosthenes on a fast computer, so longer ones are needed. }}}
I hope you regret writing that.
For 128 bits (39 digits), you almost certainly need a better than O(n^(1/3)) algorithm, or an amazing constant factor in something like a Fermat method with sieves (a la Knuth). Fortunately P-1 and Rho are arguably O(n^(1/4)), and ECM is better still (arguably sub-exponential). However, if you have prior knowledge that the number is unlikely to have small factors, then at 39 digits, you may as well just roll out a QS, which is sub-exponential, and excels when there are no small factors.
Satoshi Tomabechi's PPSIQS would do the job in the bat of an eye.
Mike Scott's QS, accompanying his Miracl library, would do the job too.
Dithering is surjective, but not injective, and thus not bijective.
That makes it lossy.
Do you agree with each the above two sentences? Yes or no. If your answer's anything but yes/yes, then dialogue is probably impossible.
However, I'll be generous, I'll give you some ground -
If the user choses to map the image from a full colour domain to a paletised domain, then/yes you are right/, it is the user chosing to perform a lossy operation upon the image, and not an instrinsic fault of the PNG file format.
_However_, if the PNG format is _unable_ to compress a full-colour image down to a suitably small file size for/the application at hand/, then yes, it _is_ the fault of PNG that it _forces_ the user to apply a lossy transform to the image in order to be useful at all./In the case in hand/ this is what has happened - in order to use PNG for the application you must apply a lossy transform. PNG has been the cause for the loss.
If there was no file size requirement, then PNG wouldn't have caused the loss. GIF would have too.
However, that would be a different situation. Go look at Bonker's post - he's quite clear about the context he's working within. Quite clear.
Anyway, what do you mean by a "format" being "lossy"? Do you mean the compression algorithm? I find that naive. The most important part of the "format" to me is the _domain_. Lossless compression's a simple matter of encoding, and relatively unimportant compared with the domain.
Off topic, off schmopic. Coffee is important, and everyone's got Karma to burn, haven't they? (Karma To Burn are a great heavy prog stoner rock band, for reference, check'em out.)
Some styles of coffee are made from water at only a fraction under 100C.
Drip percolators I think recommend lower temperatures purely because it's harder to maintian a higher temperature in a dripping setup, compared to a steam-pressured ones.
98 degrees or nothing for me:-) (Search for 'Royal Coffee Maker' if you want to see my next caffiene-oriented purchase...)
In reply to "... PNG is *NOT* lossless at lower bit-depths and has to dither..."
you blurted "... the PNG format which is lossless at all colour depths."
You, sir, are a fool, as when presented with facts you reject their correctness and reply with nonsense.
Dithering is lossy. Full stop.
Please log out of slashdot, turn off your computer, and do not return until you promise to only involve yourself in fields in which you have a modicum of knowledge. Before you do that, print out a copy of the post that you replied to, as it contains information that will be of use to you if you ever chose to learn something about image compression.
Third courses are possible, they just require imagination.
(For example, is it impossible for Apple realise they aren't going to make a cent off this and that they genuinely risk disaffecting huge proportions of their customer base, and decide that they should offer it at only $25/year instead, or a $15 special. Or even reversing the decision entirely, but I think that's less likely.)
You want it, they offer it, you gotta pay what they ask, or tell 'em to stick it.
I won't jump to any particular conclusions until I see stats about what proportion subscribe at this price.
However, if it's many subscribing, then that would reinforce the stereotype of Mac users having more dollars than sense, and if few subscribe then it would indicate that Apple don't really understand the market. Neither would be particularly big news - no offense to either side - as these are opinions that large numbers of people already have. Note however, that the flip-sides should _cancel_ the prejudice that's unfounded, but as we know it's almost impossible to get people to drop prejudices.
Better than double checking everything is to have an external eye code review everything. It's probably a 10% overhead when it comes to the coding side, but a >50% decrease in the debugging side. Well worth it.
I'm currently on sabbatical, but I consult 1 day a fortnight for a couple of small local companies who can't afford me full time - all I do there is code review, and they are of the opinion that I more than double the effectiveness of their less experienced programmers.
Can you use the same fibre for this quantum secure 60bps channel for your standard traffic too, or would they interfere?
If you could do both in parallel, I can see this being a very tasty system indeed, being only the cost of the more expensive part (slow/secure vs. fast/not-secure).
It you're trying to be descriptive, be clear. I don't think it was clear at all. Look at his follow-up - that's even less clear!
There is no egg.
THL
Re:Lempel-Ziv?? [Re:Off the top of my head]
on
Deep Algorithms?
·
· Score: 1
Holy Baloney - I invented LZP in about 1990. I needed a quick hack scheme to compress some text, and decided that the 1-bit guess was the way to go, as long as about 50% of the time the guess was correct, which is a simple matter of modelling well enough...
It's funny - being nothing more than an amateur and hobbyist, you get to invent all kinds of things and never have a clue whether they're in the academic literature or not.
THL.
Re:Lempel-Ziv?? [Re:Off the top of my head]
on
Deep Algorithms?
·
· Score: 1
Ah, Bloom. OK, I seem to remember that last time I was told to go look there my bloody PS viewer didn't work, and I gave up.
You're a dude for posting that link - you'll get my eternal gratitude if you can post a good review of the PP* family. From teh one-line I've heard it doesn't seem like it's anything new at all, it's just an dynamic adaptive-depth modeller. And great for thrashing caches.
THL.
Re:Are sorting algorithms "deep"?
on
Deep Algorithms?
·
· Score: 1
" Then it sends finer ones, and finally the last comb is the same as the 'exchange consecutive elements only' step in... "
bubblesort.
Not " quicksort. "
Ooops. I hope it was obvious that was a simple braino.
Slashdot Mirror
Funny, Roy!
Mark me down for 2 please.
THL.
Say I wished to distribute a working copy of some JavaScript code on my web-site.
So I'd need to have a click-through before the JavaScript was served.
So I'd have to write a new page and maybe a new script to handle that click-through.
However, being the stubborn GNU-head that I am, I'd insist that this click-though page should be open source too.
So I'd need a click-through before that page was served.
Lather, rinse, repeat...
THL.
There's more than just "a lot wrong" in my book. As soon as you wrap a program up with some obligation for the user (installer) to actaully _do_ something particular (read and affirm an agreement), you are restricting the user's freedom to simply to do what he wants with the code (for himself), i.e. going against the OSI way of thinking.
I don't think click-through and OSI mix, and I'm glad the decision was made that way.
THL.
"
.gz, so you don't even unzip it before you do the checking.
How can you trust a package to check it's own MD5 checksum?
"
You don't.
The checking must be done prior to doing _anything_ with the not-yet-trusted package.
It's a md5 of the
"The installer" refers to a trusted program that may download, check, unpack, compile, install, and configure a new package.
It does not refer to the new package's own 'make install' behaviour.
Almost all the major distributions (of various Un*ces) have some kind of package installer nowadays.
THL.
Why not check the MD5 checksums? Or use a package control system that automatically checks the checksums. You really can't get much simpler than that.
THL.
Not true. It _does_ affect the behaviour if the constructors or destructor have side effects (such as static instance counters, or cout<
However, the standard explicitly indicates that this optimisation and change in behaviour is permitted, and therefore that you mustn't rely on every apparent constructor actually being called.
The reason the change in behaviour was permitted by the standards body is because it decided that the potential for optimisation would be worth it.
THL.
Exactly.
I think that any operating system with the 'cp' or 'copy' command should be made illegal under the DMCA, these 'su' issues are merely red herrings.
THL.
I too read it as "full disclosure unless bound by prior contract", which I interprested as what you say. It's not well worded, but it's not actually wrong.
THL.
Agreed.
I reckon that it would be interesteing if the P2P networks were to have a "cry for help" facility, such that if a peer thought it was being dDOSed by the RIAA or whomever else, it would summon help from other peers. Hmmm, currently the only 'help' I can imagine is a return dDOS against the RIAA.
Welcome to the MAdD scenario, Mutually Assured distributed Destruction!
Of course everyone apart from those who paid off the politicians would probably end up in jail - remember to leave your computers switched on, though, as they arrest you.
THL.
{{{
RSA can be broken by factoring a large number, and a 128-bit number poses little challenge for even the Sieve of Eratosthenes on a fast computer, so longer ones are needed.
}}}
I hope you regret writing that.
For 128 bits (39 digits), you almost certainly need a better than O(n^(1/3)) algorithm, or an amazing constant factor in something like a Fermat method with sieves (a la Knuth).
Fortunately P-1 and Rho are arguably O(n^(1/4)), and ECM is better still (arguably sub-exponential). However, if you have prior knowledge that the number is unlikely to have small factors, then at 39 digits, you may as well just roll out a QS, which is sub-exponential, and excels when there are no small factors.
Satoshi Tomabechi's PPSIQS would do the job in the bat of an eye.
Mike Scott's QS, accompanying his Miracl library, would do the job too.
THL.
One sentence appended to the wrong paragraph:
...
...
{{{
PNG has been the cause for the loss.
If there was no file size requirement, then PNG wouldn't have caused the loss. GIF would have too.
}}}
should have read:
{{{
PNG has been the cause for the loss. GIF would have too.
If there was no file size requirement, then PNG wouldn't have caused the loss.
}}}
THL.
Dithering is surjective, but not injective, and thus not bijective.
/yes you are right/, it is the user chosing to perform a lossy operation upon the image, and not an instrinsic fault of the PNG file format.
/the application at hand/, then yes, it _is_ the fault of PNG that it _forces_ the user to apply a lossy transform to the image in order to be useful at all. /In the case in hand/ this is what has happened - in order to use PNG for the application you must apply a lossy transform. PNG has been the cause for the loss.
That makes it lossy.
Do you agree with each the above two sentences? Yes or no. If your answer's anything but yes/yes, then dialogue is probably impossible.
However, I'll be generous, I'll give you some ground -
If the user choses to map the image from a full colour domain to a paletised domain, then
_However_, if the PNG format is _unable_ to compress a full-colour image down to a suitably small file size for
If there was no file size requirement, then PNG wouldn't have caused the loss. GIF would have too.
However, that would be a different situation. Go look at Bonker's post - he's quite clear about the context he's working within. Quite clear.
Anyway, what do you mean by a "format" being "lossy"? Do you mean the compression algorithm? I find that naive. The most important part of the "format" to me is the _domain_. Lossless compression's a simple matter of encoding, and relatively unimportant compared with the domain.
HAND,
THL.
Off topic, off schmopic. Coffee is important, and everyone's got Karma to burn, haven't they? (Karma To Burn are a great heavy prog stoner rock band, for reference, check'em out.)
:-)
Some styles of coffee are made from water at only a fraction under 100C.
Drip percolators I think recommend lower temperatures purely because it's harder to maintian a higher temperature in a dripping setup, compared to a steam-pressured ones.
98 degrees or nothing for me
(Search for 'Royal Coffee Maker' if you want to see my next caffiene-oriented purchase...)
THL.
In reply to "... PNG is *NOT* lossless at lower bit-depths and has to dither..."
you blurted "... the PNG format which is lossless at all colour depths."
You, sir, are a fool, as when presented with facts you reject their correctness and reply with nonsense.
Dithering is lossy. Full stop.
Please log out of slashdot, turn off your computer, and do not return until you promise to only involve yourself in fields in which you have a modicum of knowledge. Before you do that, print out a copy of the post that you replied to, as it contains information that will be of use to you if you ever chose to learn something about image compression.
Sheesh,
THL.
The linux one has 2 network controllers, the MS one has only one. That ought to work in Lunix's favour.
FP.
Third courses are possible, they just require imagination.
(For example, is it impossible for Apple realise they aren't going to make a cent off this and that they genuinely risk disaffecting huge proportions of their customer base, and decide that they should offer it at only $25/year instead, or a $15 special. Or even reversing the decision entirely, but I think that's less likely.)
THL.
You want it, they offer it, you gotta pay what they ask, or tell 'em to stick it.
I won't jump to any particular conclusions until I see stats about what proportion subscribe at this price.
However, if it's many subscribing, then that would reinforce the stereotype of Mac users having more dollars than sense, and if few subscribe then it would indicate that Apple don't really understand the market. Neither would be particularly big news - no offense to either side - as these are opinions that large numbers of people already have. Note however, that the flip-sides should _cancel_ the prejudice that's unfounded, but as we know it's almost impossible to get people to drop prejudices.
THL.
Better than double checking everything is to have an external eye code review everything. It's probably a 10% overhead when it comes to the coding side, but a >50% decrease in the debugging side. Well worth it.
I'm currently on sabbatical, but I consult 1 day a fortnight for a couple of small local companies who can't afford me full time - all I do there is code review, and they are of the opinion that I more than double the effectiveness of their less experienced programmers.
THL.
Ah, OK. I was hoping that the two chanels could have been stuck on wildly different wavelengths.
Ne'er mind.
THL.
If they couldn't be clever, they could at least have been crude. Why couldn't it have been a merger between VAlinux, Gigabyte, nVidia and AMD.
Now that's a system I'd buy...
THL.
Can you use the same fibre for this quantum secure 60bps channel for your standard traffic too, or would they interfere?
If you could do both in parallel, I can see this being a very tasty system indeed, being only the cost of the more expensive part (slow/secure vs. fast/not-secure).
THL.
It you're trying to be descriptive, be clear. I don't think it was clear at all. Look at his follow-up - that's even less clear!
There is no egg.
THL
Holy Baloney - I invented LZP in about 1990. I needed a quick hack scheme to compress some text, and decided that the 1-bit guess was the way to go, as long as about 50% of the time the guess was correct, which is a simple matter of modelling well enough...
It's funny - being nothing more than an amateur and hobbyist, you get to invent all kinds of things and never have a clue whether they're in the academic literature or not.
THL.
Ah, Bloom. OK, I seem to remember that last time I was told to go look there my bloody PS viewer didn't work, and I gave up.
You're a dude for posting that link - you'll get my eternal gratitude if you can post a good review of the PP* family. From teh one-line I've heard it doesn't seem like it's anything new at all, it's just an dynamic adaptive-depth modeller. And great for thrashing caches.
THL.
" ...
Then it sends finer ones, and finally the last comb is the same as the 'exchange consecutive elements only' step in
"
bubblesort.
Not
"
quicksort.
"
Ooops.
I hope it was obvious that was a simple braino.
THL.