Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
mjb
searching PlanetScale…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
55 ms
·
541.
▲
by
mjb
15y ago
> ECC checking memory There is a balance, and I don't feel that throwing out ECC memory is necessarily the right choice for the majority of server applications. Low hardware cost needs to be achieved with an holistic approach - simply b
542.
▲
by
mjb
15y ago
As you try and push a system towards 100% reliability, you need to understand your risk model better and better. When you get to levels around 5 nines, very unlikely events which could cause an hour's outage every 20 years start to dominate
543.
▲
by
mjb
15y ago
Not really, no. The speed of light in air is very nearly identical to the speed of light in a vacuum. Wikipedia gives the refractive index of air as 1.0003, which is the ratio between the speed of light in a vacuum and the speed of light in
544.
▲
by
mjb
15y ago
Starting with something like a GNU Radio board ( http://gnuradio.org/ ) and a commercial antenna, you could put together a basic CW or ICW radar in a weekend without too much trouble. A little bit of care is required to not break any local
545.
▲
by
mjb
15y ago
You say: > I learned a lot in that, and one thing that actually surprised me is that in many cases, I was able to make a good argument that Einstein was wrong, and there was no empirical evidence to support his view on the particular po
546.
▲
by
mjb
15y ago
There are ways to text match against encrypted documents, at least approximately, without requiring homomorphic encryption. One simple scheme would be to encrypt in ECB mode (which has it's own disadvantages, which I'll ignore for now). The
547.
▲
by
mjb
15y ago
You are indeed correct. That's kind of how it worked in my head (about 12x change) but I didn't type it that way for some reason.
548.
▲
by
mjb
15y ago
We aren't there yet, not by a long shot. Taking clock cycles as the base factor, a disk seek on a modern drive (8ms seek, 4GHz CPU) takes 32 million cycles. On the Cray1's 80MHz CPU, 32 million cycles is 400ms which would be really quick fo
549.
▲
by
mjb
15y ago
Latency has been scaling worse than almost any other factor for nearly the entire history of computing. The latency/throughput ratio for storage, networking, memory, cache and almost everything else has been rising continuously since the 70
550.
▲
by
mjb
15y ago
> One cannot compete with Linux (Ubuntu/RHEL/CentOS) communities in matters of testing and code quality. No code is better tested than those included in mainstream kernel or a polular distribution. I know I'm feeding the troll here, but
551.
▲
by
mjb
15y ago
> (1) if they go mass market, all that electricity will still have to be generated somewhere. Coal? Nuclear? All of these alternatives are probably better than generating the same power, less efficiently, distributed over a fleet of sma
552.
▲
by
mjb
15y ago
Of course it's worth implementing better data structures in Python. There are two ways to make a Python program faster: make the Python program faster, or implement computationally intensive parts in another language (including using a libr
553.
▲
by
mjb
15y ago
> It's bad enough when someone opens the tiny windows we have right now. I really like looking out of the plane, especially when flying over amazing places like the arctic tundra, the Sahara, chains of islands and the like. I feel that
554.
▲
by
mjb
15y ago
> Caches are under a lot of pressure these days. More from data sizes than code sizes, at least in most performance-critical applications. Sure, bigger pointers will lead to higher miss rates in caches that contain code, but that is unl
555.
▲
by
mjb
15y ago
> Is there a reason to run a 64-bit browser? (Other than the fact that amd64 provides more GPRs?) Increased effectiveness of ASLR (Address space layout randomization) and PIE (position independent executables) is one such reason. Using
556.
▲
by
mjb
15y ago
The key thing here is that compressed sensing is an attempt to throw away redundant data as early as possible in the process. Any data which is redundant in the actual data stream, or can be inferred from prior knowledge about the stream do
557.
▲
by
mjb
15y ago
I really like this, not because it's an excellent quantitative presentation of the data, but because the 3D makes it really easy to visualize distances and scales. Some interesting things to note: - Amazingly, given the long history there,
558.
▲
by
mjb
15y ago
> None of those "obscurity" measures do anything meaningful to improve your security That's just not true. Consider a practical analogy: the access ID badges that many companies issue to their employees. Most of the time, these badges d
559.
▲
by
mjb
15y ago
> Not only that, but the behavior of some cases in hardware VMM layers can cause pretty much complete TLB wipes, thus destroying cache coherency and any memory optimizations the web server takes advantage of. It is certainly true that V
560.
▲
by
mjb
15y ago
I think it comes down to which problem you are trying to solve: 1) Recover enough to understand the program and make small changes (this is the cracking case). 2) Recover the original code of the program or something close to it, that can b
561.
▲
by
mjb
15y ago
I don't thing strong AI would solve the problem, because one crucial piece of data is lost when the code is compiled: the intention of the programmer. Good code clearly indicates its intended function through structure, most of which does n
562.
▲
by
mjb
15y ago
It makes a big difference, because compression and TV settings are very much different things. Compression aims for perceptual transparency: which data can be removed from the signal while not changing a human's experience of that signal? T
563.
▲
by
mjb
16y ago
They are more likely due to properties of the puzzles themselves than operating system behaviour, especially on a modern operating system on a multi-core machine. Plus, in the original Norvig article ( http://norvig.com/sudoku.html ) he tal
564.
▲
by
mjb
16y ago
Thanks for the answers, this is very interesting. > Yes. (Technically, append-at-head and delete-from-tail only.) Do you handle this by breaking the DB up into multiple small files, like BDB-JE? > The code keeps track of how much ga
565.
▲
by
mjb
16y ago
> It is a durable, consistent, high-performance key-value data store built out of a background-garbage-collected log-structured B+Tree. Some questions for Colin, if he reads this thread: I assume log-structured implies 'append-only'. Is
566.
▲
by
mjb
16y ago
If you are interested in datacenter design, distributed systems or just large services, I would recommend following James Hamilton's blog: http://perspectives.mvdirona.com/ . James covers a very wide range of topics, and is great about lin
567.
▲
by
mjb
16y ago
You are right about reuse across multiple internal systems not being strongly discouraged. Where it does discourage reuse is across multiple systems, and with websites. Making me change my corporate password every 90 days is an effective wa
568.
▲
by
mjb
16y ago
> They don't get weaker over time. Passwords do get weaker all the time, to the extent that they are used in multiple places. Changing the password on different systems on different schedules discourages password reuse. It also means th
569.
▲
by
mjb
16y ago
> (Single query tag lookup; naively joins the entire taggings and tags tables before limiting with WHERE) Really? Which modern RDBMS database actually works like this when indexes are available? Index selection and optimization is a sta
570.
▲
by
mjb
16y ago
Articles like this illustrate why the media should be delivering statistical data in ways that people find easier to think about and avoid common pitfalls of statistical understanding. The mean (typically called 'the average' in publication
More ›