jbri

It's in the field of copyright rather than patents, but the Righthaven suits suggest some form of precedent in this area.

But that's kind of a sideshow - I believe the real issue being pointed at is if the defendant chooses to argue that a patent is invalid, and succeeds, then the only award they get is the now-invalidated patent.

> again, maybe I'm getting old, but to see the pixels on my current screen I have to get my nose almost right up to the display, which I'm never going to do

The point of going to higher and higher resolutions is that eventually, you don't see the pixels. Pixels are an implementation detail, what you're really wanting to see is the image they represent.

Of course, the reason that language was introduced into the standard was primarily to mitigate this sort of attack.

The author mentions that he only evaluated drives that have some form of power loss protection - doing some quick searching around, I couldn't find any Samsung drives in the given price range that claimed to have that.

Did I miss an appropriate Samsung drive in my quick searches? Or is there reason to suspect that a Samsung drive that doesn't claim to have power loss protection would nonetheless handle this case better than the non-Intel drives that did make that claim? Because if not, then I don't think not evaluating Samsung drives compromises the results in any way.

Given that these techniques seem to be well-known, it would be interesting to see a JPEG compressor which uses what we know of human vision to minimize filesize while keeping the image visually the same.

JPEGmini seems to go partway with selective compression, but it seems like there's room to improve the actual compression algorithm to do things like gaussian smoothing instead of just truncating the high-frequency components to reduce filesize.

If you want to build new crypto, people would be absolutely happy for you to design and present a new cryptographic scheme - hopefully with some advantages over existing ones. People will analyze it, tell you where the weaknesses are, and if they're not critical flaws you can fix them and come out stronger - and if they are critical flaws, you know your scheme is broken before it's been used for anything important.

Likewise, building a hot new secure messaging app with existing well-analyzed, battle-tested cryptographic schemes is generally going to be welcomed.

If you try to do both at once, you're building your application on shaky, untested cryptographical foundations. Cryptographers would similarly probably warn you not to base your application on a new cipher someone else announced at a cryptography conference last week - give it a bit of time for others to analyze it and spot any flaws it might have before you entrust anything sensitive to it.

If people want to support the TrueCrypt developers, there's a "Donate" button on the TrueCrypt website. People have instead chosen to give money to an initiative to have a thorough independent audit of the TrueCrypt code - it seems to me like it would be morally wrong to take their money and give it to the TrueCrypt developers instead. Presumably, if their preference was for that money to go to the TrueCrypt developers instead, they'd have skipped the middleman and donated directly.

Perhaps someone should organize a similar initiative for the Linux source code?

On the other hand, if you allow outside communication (such as unrestricted access to the internet), you open the door for "I'll pay someone who already knows this stuff to phone in the answers for me" - which isn't generally an applicable skill in the real world.

As an aside, I hated open book exams - if you were talented and knew the material, you could typically blast through a closed-book examination in half the allotted time and get out of there, while the open-book exams were far longer and more tedious.

I'll confess I'm not intimately familiar with the details of this case, and I'm speaking in generalities.

But still - it doesn't matter whether the charges are invented or not, or even what those charges are. What matters is that a judge (not the police) ruled that he should be held until his trial.

It shouldn't matter whether these specific charges are made-up or not. At this point they're unproven allegations, and it's up to a court to decide whether they're valid or not.

It's important to realize that anytime you give the police power over people still facing trial, you give them that same power over anyone they can fabricate spurious charges against. That's why it's important to have things like warrants and pre-trial court orders, so that there's some accountability when the police detain someone over unproven allegations.

In theory? Quantum and thermal effects inside an unstable configuration of transistors.

The simple example is a basic SR latch (two NOR gates, where the output of one gate feeds one of the inputs of the other, and vice versa), where you start things off by applying a signal to both S and R. When you remove the signals, the latch will eventually fall back into one of the two stable states - but which state it ends up in is random.

So you can easily produce a stream of bits from a potentially-biased random source, and then do some deterministic massaging of that stream to produced an unbiased stream of random bits.

> and early PS3 were reluctantly compatible with the PS2.

And they did that by effectively putting a PS2 inside the case alongside everything else, ironically making backwards compatibility one of the things contributing to the high price and hence slow early adoption of the PS3.

It seems unreasonable to claim that academia would reject the idea out of hand when no-one's even written a paper to attempt to submit to a peer-reviewed journal.

If you showed me scientific papers that had been rejected by peer reviewers, then you might have a point. But if it's entirely articles targeted at laypeople and no scientific papers, it's pseudoscience.

Reading your link, it appears that the author just flatly assumes that space is not expanding, and everything else stems from that assumption.

The author provides another article to attempt to support that assumption, but their argument for that is incomplete, and while their alternative appears to offer explanations for some observations, it ignores other things (like cosmological redshift). Add in the fact that that the article appears targeted towards laypeople and there's no scientific paper to be found suggests that it's more psuedoscience and thought experiments than actual scientific investigation.

It seems unreasonable to claim that academia would reject the idea out of hand when no-one's even written a paper to attempt to submit to a peer-reviewed journal. I suspect the reason academia ignores the supposition is not commercial interest like you claim.

The primary reason people use monospace fonts is historical inertia. It's definitely worth trying out a proportional font if your environment is amenable to it (some tools don't cope particularly well, for sad and disappointing reasons).

The optimal mechanism is to indent with tabs, and align with spaces (that is, you have the same number of preceding tabs as whatever you're trying to align with, and then use spaces from there).

Though setting your editor up to do that automatically is an incredible pain, and it kind of forces you to use a monospace font.

I believe the big reason for the power-efficiency is that it's entirely clockless - the power consumption of an idle transistor is very low compared to one that's switching, and a central clock causes many, many transistors to switch every clock cycle. Being clockless is another way to only pay the power cost for silicon that's actually doing something.

Another thing I've been looking at it for is that the design makes it very easy to bit-bang protocols - if you can't get an off-the-shelf chip to speak a protocol for you, using one of these is far cheaper than sticking an FPGA in there, and is similarly cheaper (and easier to patch later) than getting a custom chip unless you're doing a truly massive run of devices.

Honestly it seems fairly obvious to me - "clocks changed" is kind of the first assumption you make when two time strings that appear very close together parse as far apart.

After that, it only takes some quick googling to figure out what happened at the end of 1927 that could affect things.

The electric eel has lots of insulating fat just under the skin - so it wouldn't be too much outside the realms of plausibility for it to have higher electrical resistance than something made primarily of muscle.

Of course, the insulating fat also likely provides a sort of faraday cage effect - any current that does hit the eel will just flow through its skin instead of hitting anything important.

No, that's not it.

If you restart the simulation a few times, you should eventually get something where everything forms into one clump with low initial angular momentum. If you keep watching from that point, you'll see the clump's rotation accelerate entirely on its own.

I'm not entirely sure on the cause, but it does seem to be a simulation flaw.

Something seems off about the simulation - once you get a big clump, it starts spinning faster and faster until it tears itself apart again.

Ignoring that, it's pretty neat - and runs decently fast as well.

That seems like a bit of a sideshow, considering they'd get exactly the same (combined) amount of money if they weren't living together.

What makes it any different from a bunch of working adults living in a large house and splitting the rent?

> those keyboards that result in vi/vim not being able to exploit control characters.

Modern vim uses control characters just fine. Have you used it any time in the last decade?

Because you seem to dance around that question a lot, saying "Well when did I say I haven't used vim recently" whenever someone brings it up, and then saying something else completely wrong that indicates you have no idea how a modern version of vim is actually used.

That seems like the wrong way to do it.

The post sentence spacing was never really treated as two consecutive spaces - conceptually, it's a single area of whitespace that is larger than the inter-word spacing.

If you especially cared about typesetting it correctly, you'd use a single   (or perhaps an  ).

There is indeed a massive advantage of a mouse over a keyboard-based interface - it's far, far more discoverable for novice or occasional users. In fact, I'd venture to say the mouse (and the corresponding advent of discoverable graphical interfaces) was the primary driver of making computers accessible to non-techies and hence largely responsible for the computing revolution.

But, a keyboard-based interface is still more efficient for someone who can put in the time to learning how to use it efficiently (and customizing it to their specific work), and uses it regularly enough to maintain that knowledge. For a lot of people who write code for a living, a text editor definitely falls in that area.

I'll point out that any modern version of vim uses mice just fine. It also uses the system clipboard just fine.

The reason most vim users stick with the keyboard is because using a short key combination to select and manipulate text is measurably faster than moving your hand off the keyboard, manipulating a mouse or touchscreen, and then moving it back to continue typing.

To me, it sounds like he's made the classic "vim newbie" mistake of thinking of insert mode as the default, and then switching to normal mode to do anything other than edit text. It's easy to see how that would cause a painful experience.

Flexbox[1] addresses the issue you're talking about - of course, browser support is still a little lacking (No support for IE9 or below, and IE10 doesn't conform to the current spec).

[1]: https://developer.mozilla.org/en-US/docs/Web/Guide/CSS/Flexi...

I'm confused. At some points you talk about "The" JVM as if there is only one, yet in other places you suggest there are multiple ones that offer different tradeoffs.

When someone says "The JVM does that", are they talking about all JVM implementations? Just a subset of them? How do you tell them apart?

Well, it's not 128k random bytes, a large chunk of that is compiled executable code. That weights things very much towards sequences of opcodes that achieve something when executed.