Why get a publisher? It's trivial to contract out most of the rest of it and you get to keep a larger slice of the money. It's not like in olden times when you needed a publisher in order to get a book in front of customers.
I wasn't writing my book for money. I was writing it to educate people and lay out the correct way of thinking about a particular technical topic. When I agreed to sign up with a publisher who was pestering me to let them, it was because it meant I didn't have to go to the trouble of getting books made, copy editing, dealing with distributors, getting ISBNs and all the rest.
A hash of the metadata (if by this you mean the output of the voice print, as "Mrs Miggins, The Pie Shop, The High Street, East Cheam, is also metadata) might not allow the matching to work, depending on how it has been implemented.
Ding Ding Ding! Unless someone can replicate a sound exactly, comparing a new hash to a recorded hash will fail.
So I take it the Slashdot community hasn't spent their time studying the theory of fuzzy hashing and secure sketches. http://web.cs.ucla.edu/~rafail...
The mechanisms of efficient energy storage and release mitigating spot market abuses by generators is simple to understand and has been shown to work in practice. I didn't make an argument of authority, I pointed to reports of it working when deployed.
>But will this technique leak information about the contents of other XPoint memory addresses?
It will open up interesting attack vectors, yes.
1) If the information capacity of the checksum is less than the data being checksummed, you will be able to find collisions and maybe use this to cause targeted data corruption. 2) Any 'lazy/speculative/delayed' execution has turned out to be a side channel vector in recent years. 3) If CRCs are used instead of cryptographic hashes, then targeted data modification can yield checksum collisions with presumably unintended consequences.
And shit like this is why I will stick with my TomTom instead of a damned phone to navigate.
My TomTom isn't dependent on a network connection, someone else's servers, or anything outside of my car besides the actual satellites. And, nobody gets to track me for advertising purposes.
On-line stuff has a bad habit of failing you at the least opportune moments.
There's nothing more hilarious than one of the phone zombies who finds themselves out of signal range -- no Facebook, no music streaming, no cat videos... just them and a phone which can no longer do anything for them. They just stare at their phone like their world has just collapsed.
I'll stick with my dedicated iPod and GPS which are immune to this crap, and doesn't include ads, analytics, or DRM.
So you haven't worked out how to download offline maps on your phone?
Yes. I once though it would be a good idea for them to adopt beos. I used BeOS back in those days, but now the unix like underpinnings of macos is a lot better.
The transition from the Apple dialect of object pascal did indeed happen as a result of the NeXT transition. That's just more historical detail. They did transition from pascal -> object pascal -> Objective C -> Switft.
I'm talking about Apple's adoption of languages. If you are of a certain age, you will remember a time before NeXT, before SJ left Apple when there were Apple ][s, Apple//es, Lisas, Early Macintoshes. At no point did I claim that Apple invented these languages. Why are you implying I did? Why is the name of the creator of Objective C relevant to my statements about Apple's adoption of Objective C?
You may be 12 years old and so were not around when these things happened. Some of us are older and remember it well.
...And that was true of Obj-C for the last 30 years, so... yeah, solid argument there....
Obj-C was not developed by Apple. It was used by Apple (and, btw, NeXT), but it was developed separately from Apple by StepStone.
Because Apple used Pascal, then extended it to object pascal. Then people wanted C, but they needed object semantics to port the object pascal libraries and C++ wasn't ready and was ugly as sin, so they went with Objective C, which is uglier. They were swept along with the stream like everyone else.
The real problem with Swift is not the language, it's that when you try to use swift to program a mac or iphone, you spend most of your programming time interacting with the libraries in arbitary ways invented by Apple and every example on the internet seems to be written in Objective-C. You're left guessing at what the Swift equivalent would look like.
>It is perfectly well known for which tasks quantum computing will be more efficient than conventional computing
But as the poster you rudely accused of posting nonsense wrote, it's never been demonstrated.
There are legitimate reasons to think it will never happen: Noise, cost scaling of maintaining low entropy space, incompatibility between quantum error correction on qbits and doing logic on those qbits.
I'm a sceptic. I don't expect to see the ECDLP for deployed key sizes solved by quantum computers, ever.
Slashdot Mirror
What tense is that supposed to be?
sub perfect
Why get a publisher? It's trivial to contract out most of the rest of it and you get to keep a larger slice of the money. It's not like in olden times when you needed a publisher in order to get a book in front of customers.
I wasn't writing my book for money. I was writing it to educate people and lay out the correct way of thinking about a particular technical topic. When I agreed to sign up with a publisher who was pestering me to let them, it was because it meant I didn't have to go to the trouble of getting books made, copy editing, dealing with distributors, getting ISBNs and all the rest.
The heavy cream latte I buy in the Starbucks that is 30 seconds walk from my house seems to be pretty low sugar.
I'm about to have a book published. I guess I'll get to find out if my publisher is more or less slimy than Addison-Wesley.
Are you dead yet?
Thought not.
That's how it works.
Only if they build a powerwall with said batteries.
My employer's corporate filter totally blocked that.
New ones don't help. There is still lag with bluetooth.
> Google hardware isn't bad, and neither is Apples Software.
I see you're not an iTunes for Windows user.
It's pretty bad on MacOS too.
A hash of the metadata (if by this you mean the output of the voice print, as "Mrs Miggins, The Pie Shop, The High Street, East Cheam, is also metadata) might not allow the matching to work, depending on how it has been implemented.
Ding Ding Ding! Unless someone can replicate a sound exactly, comparing a new hash to a recorded hash will fail.
So I take it the Slashdot community hasn't spent their time studying the theory of fuzzy hashing and secure sketches.
http://web.cs.ucla.edu/~rafail...
So present an argument with substance.
The mechanisms of efficient energy storage and release mitigating spot market abuses by generators is simple to understand and has been shown to work in practice. I didn't make an argument of authority, I pointed to reports of it working when deployed.
Euphoria is bad, MMkay?
I see no evidence supporting the claim above in three of the four articles above. I won't bother with the fourth.
Musk fans are like their cult leader, they can only do one thing - lie. And not very well.
I see no evidence in your outlandish claims. Anonymous cowards who lie a lot don't carry much weight in an argument.
You really want the world to be shit place don't you?
There may be help for your problem.
It is if it adds $15k to the value of the house.
>unsupported by anything that resembles evidence
Evidence like it being widely reported in the press?
http://www.abc.net.au/news/201...
http://fortune.com/2017/12/26/...
https://arstechnica.com/inform...
https://www.washingtonpost.com...
>And the bad thing about batteries is that you can't scale them up
Yes you can. You buy some more and install them. It isn't complicated.
Rude and wrong, a winning combination.
>But will this technique leak information about the contents of other XPoint memory addresses?
It will open up interesting attack vectors, yes.
1) If the information capacity of the checksum is less than the data being checksummed, you will be able to find collisions and maybe use this to cause targeted data corruption.
2) Any 'lazy/speculative/delayed' execution has turned out to be a side channel vector in recent years.
3) If CRCs are used instead of cryptographic hashes, then targeted data modification can yield checksum collisions with presumably unintended consequences.
Ocean's Eleven Chest Holes.
And shit like this is why I will stick with my TomTom instead of a damned phone to navigate.
My TomTom isn't dependent on a network connection, someone else's servers, or anything outside of my car besides the actual satellites. And, nobody gets to track me for advertising purposes.
On-line stuff has a bad habit of failing you at the least opportune moments.
There's nothing more hilarious than one of the phone zombies who finds themselves out of signal range -- no Facebook, no music streaming, no cat videos ... just them and a phone which can no longer do anything for them. They just stare at their phone like their world has just collapsed.
I'll stick with my dedicated iPod and GPS which are immune to this crap, and doesn't include ads, analytics, or DRM.
So you haven't worked out how to download offline maps on your phone?
You're pointing out arrows of causation that I said nothing about.
Neither NeXT, nor Apple, nor anyone was adopting C++. C++ at the time wasn't ready while ObjC was.
Yes. I once though it would be a good idea for them to adopt beos. I used BeOS back in those days, but now the unix like underpinnings of macos is a lot better.
The transition from the Apple dialect of object pascal did indeed happen as a result of the NeXT transition. That's just more historical detail. They did transition from pascal -> object pascal -> Objective C -> Switft.
>You have your history completely wrong.
Not at all.
I'm talking about Apple's adoption of languages. If you are of a certain age, you will remember a time before NeXT, before SJ left Apple when there were Apple ][s, Apple //es, Lisas, Early Macintoshes. At no point did I claim that Apple invented these languages. Why are you implying I did? Why is the name of the creator of Objective C relevant to my statements about Apple's adoption of Objective C?
You may be 12 years old and so were not around when these things happened. Some of us are older and remember it well.
...And that was true of Obj-C for the last 30 years, so... yeah, solid argument there....
Obj-C was not developed by Apple. It was used by Apple (and, btw, NeXT), but it was developed separately from Apple by StepStone.
Because Apple used Pascal, then extended it to object pascal. Then people wanted C, but they needed object semantics to port the object pascal libraries and C++ wasn't ready and was ugly as sin, so they went with Objective C, which is uglier. They were swept along with the stream like everyone else.
The real problem with Swift is not the language, it's that when you try to use swift to program a mac or iphone, you spend most of your programming time interacting with the libraries in arbitary ways invented by Apple and every example on the internet seems to be written in Objective-C. You're left guessing at what the Swift equivalent would look like.
>It is perfectly well known for which tasks quantum computing will be more efficient than conventional computing
But as the poster you rudely accused of posting nonsense wrote, it's never been demonstrated.
There are legitimate reasons to think it will never happen: Noise, cost scaling of maintaining low entropy space, incompatibility between quantum error correction on qbits and doing logic on those qbits.
I'm a sceptic. I don't expect to see the ECDLP for deployed key sizes solved by quantum computers, ever.