5,397 karma · joined April 6, 2009
8½
return -ENOCOMPREHEND;
https://www.forbes.com/sites/joewalsh/2022/01/19/cdc-prior-c...
The unsaid part: "recipients are supposed to publicly laud the government": https://en.wikipedia.org/wiki/Court_painter
>bellmar.medium.com
I did a double-take to ensure it wasn't "ballmer.medium.com" :D
That sentiment fits individualist views and policies, where it behooves us to hear out individuals and consider them on their individual merits.
However the view and policy discussed (limitations on individuals for common good) is explicitly a collectivist view and policy. Applying a sweeping generalization to a collectivist view and policy is fit and proper by the very nature of collectivism.
Edit: corrected a typo from "individuals" to "individualist".
Close, but not quite there. Much of the problems we see today are because the news media are financed through marketing & PR spend.
This makes the media's Overton Window somewhat limited to what is a good side-dish to marketing & PR. Among other concerns, this causes all content to skew towards middle-class, college-educated middle manager viwepoint. That's not exactly a recipe for a great society. And that leaves many segments of the readership underserved.
>understanding dark magic
That is the original Unix black magic: KISS and do the simplest possible thing that works and when in doubt use brute force and so forth. That is the "C" language of infrastructure.
In the particular in the scenario we're discussing, there's always a pool of several servers ready to handle a HTTP request (or DB query, or multimedia transformation, etc.). Rebooting a small % of this pool, rather than debugging every single memory leak is a pragmatic, cost-effective solution. "Zero bugs" is a very abstract and detached goal; "cost effectiveness" is a very realistic and wholesome goal.
I used to think that early on in my career as developer. At this point I believe those two are fundamentally the same jobs: gathering, processing and transforming requirements from one form & language to another.
>sometimes the experienced doctor or researcher made a mistake, and the guy who posted something on Reddit is correct
Both of those points are true, and we can reconcile them thusly:
Broadly, the doctor is the fully educated, while the layman-interested-in-subject is making semi-educated guesses. However this relationship inverts on narrow subjects, like a particular rare disease: the doctor ends up making a semi-educated guess (based on his general medical education), whereas a layman with intense interest in this particular rare disease can easily be the fully educated one - again, on this particular narrow subject.
Who decides what is a "whoopsy" a legitimate user made, and what is a pretend-"whoopsy" conjured by a malicious actor? Giving people & automated systems ability to flag something as "whoopsy" and revert it or lock down entire account enables malicious abuse and honest mistakes; either can end up very costly or even effectively irreversible in some cases.
Trivial example: every day we see a new post on HN about somebody's Apple/Google/YT/payment processor/etc operation/content/account being marked as "whoopsy" by the support or anti-fraud team, and they losing access to data/finances.
The best way to think of cryptocurrencies being "too absolutist" (irreversible) is as of a complementary counterpart to the (fiat) money which is too open to interpretation and always subject to unexpected third party decisions.
There is certain irony to posting a strong "allergic" reaction to a rather mundane phrase in discussion of propaganda. One could say there was effective propaganda for the phrase to become a thought-terminating cliche.
q('select name from users where id = :userid', compact('userid'));
q('select name from users where id = ?', [ $userid ]);
The CPU has limited memory bandwidth; the larger instruction size, the more bytes needs to be loaded from memory to execute the instruction. Same with cache size - the more space an instruction takes, the lower the amount of instructions that is cached. Lastly, there's the complexity & latency of the instruction decoder. This possible performance loss is averted by keeping instructions short and instruction set "dense".
Any instruction that refers to a register needs certain amount of bits in the operand portion to indicate which specific register(s) is to be used [1][2][3]. As example, in case of 8-register x86 the operand generally uses 3 bits just to indicate which register to use. In case of 16 register x86_64, it takes 4 bits. If we wanted to use all 200 physical register, that would require whole 8 bits reserved in the instruction just to indicate the register to use. Certain instructions - data transfer, algebra & bitwise operations, comparisons, etc. - naturally use two or more registers, so multiply that accordingly.
Since using this many registers gives only diminishing return in terms of performance (and also requires very heavy lifting on compiler's part[4]), the trade-off selected is that the compiler uses architecture-defined small number of registers, and the processor at runtime is able to speed up some code using the spare registers for instruction-level execution parallelism.
[Edit]
There's one more common circumstance where large number of registers is undesirable: a change of execution context (thread switch; process switch; interrupt). Typically all architecturally-visible registers are saved to memory on a change of context and new set is loaded for the new context. The more registers there are, the more work is to be done. Since the hardware registers are managed directly by CPU and serve as more of cache than directly accessed register, they don't need to be stored to memory.
[1] Aside of certain specialized instructions that implicitly use a particular register; for example in x86 many instructions implicitly use the FLAGS register; DIV/IDIV integer division implicitly uses AX and DX registers.
[2] Aside of certain instruction prefixes that influence which register is used; for example in x86 that would be segment register overrides.
[3] Aside of certain architectures where registers were organized in a "file" and available only through a "window" - i.e., an implicit context, implicit register addressing base; instruction operands referred to registers relative to the current window, and the whole window could be shifted by specialized instructions. Typically shifted on function enter/leave and similar. This was more-or-less the whole "hardware registers" being exposed at architecture level, however in a somewhat constrained / instruction-dense way.
[4] Arranging which registers to use, which to spill to memory etc. is non-trivial work for compiler, and the complexity grows super-linearly with the number of registers.
There's a few striking errors in your post, and this one is the most glaring - in that it's very visual, and also very wrong.
Consider the photo of the Tesla (Model 3) key fob [1]: it's a small car that one does, in fact, wear in one's pocket to show it off to one's relatives or business partners.
Similar with the Tesla App [2] - it shows a desirable car on your phone's screen for the very same reason; the rest is nice extras.
I've had good luck discussing the subject back in 2013: https://news.ycombinator.com/item?id=6464807 and https://news.ycombinator.com/item?id=6465175, with the insightful replies.
Wow, reading the discussion from back then shows how much HN changed in spirit.
Ironically enough your example is flawed: there are documented 10x touch-typists.
The realities of the court system place high demands on the typists; the minimum required typing speed is already quite high: trained court reporter or closed captioner must write speeds of approximately 180, 200, and 225 words per minute (wpm) at very high accuracy in the categories of literary, jury charge, and testimony, respectively[1] - and some exceed the minimum and go for 300 wpm. Even better, the official record for American English [is] 375 wpm [2].
Compare that to the average typing speeds around 30 - 40 wpm [3] Granted, the court reporters use specialized input devices (stenotypes) - but hey, the same can be said about highly productive programmers, who use specialized development environments - and sometimes also specialized input devices.
--
[1] https://en.wikipedia.org/wiki/Stenotype
[2] ibid.
Emphasis on easily - if it ever becomes straightforward, without going through scary settings menu, Google will be quite scared.
>a custom merge driver will not make your .git grow any less than it would normally.
You can go a long way with simple homespun methods. SQL dumps delta-compress in Git very well - especially if you tweak the dump options a bit so that the row order is mostly stable.
The same most probably goes for any other textual dump - if the (unchanged) content is largely ordered in stable fashion, it will delta-compress very well, even without any explicit, specialized support in Git itself.
>I'm beginning to wonder if they aren't lobbied by fossil fuel companies.
There was a large oil-exporting and gas-exporting country that has been aligned with Green Parties' political programs back in the 80s. USSR was known to train and to sponsor activists, academics, and publishers as part of its influence campaigns.
It helps your case that the fossil fuel exporter USSR was ran in a top-down, by-fiat fashion, rather similar to how corporations function internally.
>That's because of EU regulation.
Patently untrue: the Micro USB has won over proprietary connectors before the EU regulation, thanks to being cheaper than ever-changing charging & data cables that used to be the norm. That in turn was possible through large volume, and also through well designed standard; it was the third iteration of the plug - after original full sized A/B, and after the somewhat underwhelming Mini USB.
In particular the Micro USB was specced for quite good reliability - including 10,000 plug-unplug cycles, which is quite high for consumer grade hardware, and that was made possible thanks to the sheer experience amassed over years by the USB consortium. Not by regulator's fiat.
That currently USB-C is ruling the market is again thanks to USB consortium's active push, together with large volume of all sorts of devices using it.
Absolutely!
The sheer amount of optional features in USB-C cables makes charging - in particular fast charging, and charging tablet/laptop sized devices - a hit-or-miss game.
USB-C's design was made to balance of costs with regards to client device complexity: 12 pins in total, three twisted pair signalling pathways, of which two are optional. All this is because both of need for backwards compatibility, and also current limitations on low-power, low-cost USB devices that need compat back to USB 1.1. Two thirds could conceivably be done away, using two pins for power and two for singalling. On a large volume production, a smaller number of pins pays off in costs - once Super Speed-grade transceivers are cheap enough for all devices. Alternatively, once optical interconnect becomes cheap enough, we could return to that technology - two power pins & one optical connector. For example Thunderbolt originally started out as optical connector [1], and was only later shifted to copper due to still costly technology.
A phone would also benefit from a contact connector similar to Apple's magsafes (attached via magnets) rather than insertion plug; both due to mechanical concerns and also savings on internal space. That we are stuck with plugs and sockets is largely artifact of requirements for uses other than charging, including pendrives & other USB dongles.
Lastly, a clear directionality hint to charging cables would be good: if you connect a phone to a tablet, which should charge which? Some sort of marking or indicator for the (rare) ambiguous case would be nice.
[1] https://en.wikipedia.org/wiki/Thunderbolt_(interface)#Copper...
Seems some bureaucrat has dusted off the bad old "Everything that can be invented has been invented." quote.
The only possible upside would be manufacturers standardizing on wireless charging in all devices just to avoid this limitation.
For reference: sealed-beam headlamps were introduced in 1939, becoming standard equipment across all American-market vehicles starting in 1940 and remaining the only type allowed for almost four and a half decades, until the 1984 model year. - https://en.wikipedia.org/wiki/Parabolic_aluminized_reflector...
What aircraft autopilot does is following a pre-planned route to the T, with any changes being input by humans. The aircraft autopilot doesn't do its own detection of obstacles, nor of router markings; it follows the flight plan and reacts to conditions of the aircraft. Even when executing automatic take-off and landing, the autopilot doesn't try to detect other vehicles or obstacles - just executes the plan, safe in knowledge that there are humans actively monitoring for safety. There is always at least two humans in the loop: the pilot in command who prepared and inputed the original flight plan and also inputs any route changes when needed (collision and weather avoidance), and an air traffic controller that continuously observes flight paths of several aircrafts and is responsible for ensuring safe separation between aircraft in his zone of responsibility. Beyond that, an ATController has equal influence on all aricraft in his zone of responsibility, and in case one does something unexpected, it can equally well redirect that one or any other one in vicinity. Lastly, due to much less dense traffic, the separation between aircraft is significantly larger than between cars [1] providing time for pilots to perform evasive maneuvers - and that's in 3d space, where there are effectively two axes to evade along.
Conversely with car FSD - the system is tasked both with following the route, and also with continuously updating the route according to markings, traffic, obstacles, and any contingencies encountered. This is a significant difference in quantity from the above - the law and the technology demands one human in the loop, and that human can only really influence his own car at most. Even worse, due to density of traffic, the separation between cars is quite often on the order of seconds of travel time, making hand-over to driver a much more rapid process.
I am moderately hopeful for FSD "getting there" eventually, but at the same time I'm wary of narrative making unwarranted parallels between FSD and aircraft autopilot.
[1] https://www.airservicesaustralia.com/about-us/our-services/h...
That... that doesn't influence one of the presumed ways the NN categorizes images: the trend in bone geometry. The "blobs", while fuzzy, still largely retain the relative proportions to each other. Or, in other words, proportions of image elements are invariant for operations of scaling and of blurring.
While "faster than light neutrino" was highly unexpected and rather suspect from the start, the "bone geometry differs slightly between ethnic groups" is well established among the anthropologists of humans. There are also parallels in wider biology of animals - mentioning that to underscore it's as scientifically expected, and not merely construed for humans alone.
The question here was how exactly is AI detecting it this well from chest X-rays; the question centered around AI and possibly if it would unexpectedly influence the medical processes - rather than around the bone geometry itself.
For sake of example, a random link from google search: https://www.researchgate.net/publication/24427702_Ethnic_dif...
[1] https://en.wikipedia.org/wiki/Euphemism#Euphemism_treadmill
The paper quite explicitly goes into testing and disseminating what exactly the AI detects. Two observations:
- the classification clearly was primarily based on the visual content rather than spurious metadata, because various transformations of the visual content had the expected impact on classification correctness
- the classification clearly wasn't based on one specific feature of the visual content but rather on multiple factors in the visuals, because various transformations to features (including masking out specific features like bone density) produced results matching expectations (usually gradual decrease in accuracy, with some thresholds).
Conversely, if the classification was primarily based on factors other than the visual content, the visual transformations would have had negligible effect - possibly up to a threshold, and then would throw the AI completely off.