HN user

petascale

113 karma
Posts0
Comments20
View on HN
No posts found.

Mach-E was the bestseller last month, second place this month after the Model Y. The 80% last month were for plugin vehichles including plugin hybrid (64% battery electric, BEV), the 70% now are BEV (about 88% plugin).

The numbers change a lot from month to month. Depends on delivery rate (e.g. Tesla does bulk delivery every three months), and there is typically a spike in deliveries when a model starts shipping, since there are months of backorders to work through. New models starting shipping was Mach-E last month and Model Y this month. So it's more useful to look at longer timeframes.

Sounds to me very much like "I want to learn truths and relationships about natural language that are independent of any specific culture and history", i.e. independent of any particular language and concepts like alphabets and spelling. Such things exist (like Chomsky's generative grammar), but they are of limited use in learning any particular language.

Music theory without culture and history would have to leave out things like scales, chords, chord progressions, tuning systems (like our 12-tone equal temperament), etc., since they vary between cultures and over time. I'm not entirely sure what's left, maybe the harmonic series?

Sheet music is similar to math notation or written language, and simpler to learn than either of those. It's not the only possible notation, but it's widely used and more compact than say guitar tabs or a MIDI piano roll. If you can't read/write any notation at all you will be limited by how much you can memorize, writing things down is a time-honored tradition for rememering details for yourself as well as for sharing it with others.

So I would suggest that music students learn sheet music plus any other notation that's relevant to their instrument, for the same reason I would suggest that English learners learn to read and write despite English spelling being a crapton of inconsistencies; it gives a lot more options for a modest amount of extra effort.

Can you go through life without being able to read and write, sure. I just don't see why you would want to.

240 kW according to Microsoft: https://natick.research.microsoft.com/

[They] adapted a heat-exchange process commonly used for cooling submarines to the underwater datacenter. The system pipes seawater directly through the radiators on the back of each of the 12 server racks and back out into the ocean.

https://news.microsoft.com/features/under-the-sea-microsoft-...

So watercooling with seawater, a pump or two, perhaps a heat exchanger (the radiator) is involved. Server to air to pod outer surface would be way too inefficient to keep the servers operating.

For me, the photos in the linked article look great no matter what the process was to create them. I don't see why they would lose their charm if they were CGI, simply because we tend to know whether we like a picture or not within a split second of first seeing it, while we generally don't know how they were made until later.

But for the pictures in the GP link, I don't think the pictures by themselves are all that interesting; to me almost the entire interest stems from knowing how they were made.

Somewhat comparable to pictures posted on HN a while back that went from "ho-hum, another portrait" to "that's actually interesting" by knowing that these were not real people or real photos, but rather computer generated portraits. (https://petapixel.com/2019/09/20/this-company-is-giving-away... )

So I think charm/appeal can stem from several sources, like pure visual impact, but it can also stem from an appriciation of the process behind it. And I see people sometimes change their minds on how well they like a picture - in either direction - based on how simple or complex they think the process was, even if the picture is identical. (Compare say a picture of a wild wolf pouncing its prey vs the same picture after you've learned that it's stuffed animals and the scene was arranged by the photographer.)

Quoting the article:

"While a few other substances (like solid neon) could potentially explain the coma-free acceleration, hydrogen was the best match for the data."

It doesn't have to be hydrogen. But to explain acceleration from solar heating it does need outgassing, and the outgassing has to be in a form that we can't detect (no comet tail). Stone won't have much (or any) of that.

Not all that massive: 6% increase if all cars and vans (excluding e.g. big rigs and tractors) go electric, according to the Norwegian national grid institute[1] (in Norwegian). Some local grids will need an upgrade, but the national transmission and distribution grid can handle it if 'smart' charging solutions shift the bulk of the charging to happen at night and other low-demand periods.

Norway uses a lot of electricity even without EVs, so it's not a very large increase percentage wise. E.g. we don't have gas pipes to homes like some places in the USA, so stoves are all electric and a lot of heating is electric as well.

[1] https://www.nve.no/nytt-fra-nve/nyheter-energi/stromnettet-e...

Because for a given amount of funding and engineering effort, a telescope on the ground can be a lot larger.

Hubble has a 2.4 meter mirror, TMT is 30 meters. Resolution scales with the diameter of the mirror (so an order of magnitude more for TMT), while light gathering scales with the area (two orders of magnitude more for TMT).

Traditionally, there were two challenges for large ground based telescopes: a) We couldn't make telescope mirrors larger than ~5 meters because the glass starts to deform under its own weight and the view gets worse rather than better; and b) we lose too much to atmospheric distortion.

The solution to the first issue is to assemble large mirrors from many small mirrors in a honeycomb pattern[0].

The solution to the second one is adaptive optics[1]: Actuators and computer control can compensate for atmospheric distortion by precisely deforming the mirror in real time, several times per second, to cancel out the distortion. We still need a good location for the telescope to minimize the amount of distortion we need to handle, but with that we could for the first time achieve better resolution from the ground with the 10-meter Keck.

These days the benefits of a space telescope come not so much from visible light, but from other wavelengths that are fully or partially blocked by the atmosphere[2]. Like UV, X-ray, or infrared like the upcoming James Webb space telescope.

[0] https://www.wired.com/2008/10/in-the-late-197/

[1] https://en.wikipedia.org/wiki/Adaptive_optics

[2] http://gsp.humboldt.edu/OLM/Courses/GSP_216_Online/lesson2-1...

With higher resolution sensors, small imperfections are more visible. To extract the most from a high-megapixel camera, you need spot-on focusing, a higher quality (more expensive) lens, and more care (e.g. higher shutter speed or tripod) to avoid camera shake during exposure.

If you nail all these, I wouldn't call it crappy even at 1:1.

But there is a residual imperfection from the Bayer pattern on the sensor, since each pixel records only one color (R, G, or B) and the other two values for that pixel have to be guesstimated from neighboring pixels, so the de-bayering process isn't perfect.

One way to fix it is to use a monochrome sensor and color filters, taking 3-4 exposures (luminance/mono plus R/G/B) and stack them.

A few cameras on the market have a pixel shift feature that can do something similar - multiple exposures, shifting the sensor one pixel between exposures so each pixel get a true R/G/B sample, and stack them in camera or in post.

Edit: Forgot to mention the anti-aliasing filter. It sits in front of the sensor and deliberately blurs the image at the pixel level. This is done to avoid aliasing and moiré artifacts, but obviously has the side effect of not-so-great image quality at the pixel peeping level. The fix for this is to get a camera without an AA filter, many modern high-resolution cameras don't have them.

https://www.outdoorphotographer.com/photography-gear/cameras...

How many I/O devices/drivers does a pacemaker talk to?

A pacemaker would presumably be similar to Arduino: A simple processor, no OS. 100k lines (your numbers) isn't all that much, given that C standard libs are into the tens of thousands alone. Pacemakers have sensors to detect heartbeat, logic to send an electric pulse only when needed, and have an interface where medical personell can hook up a computer to adjust some parameters. So 2-3 IO channels at a minimum (one or more sensors, one or more outputs for the electric pulse, and some sort of wireless interface for adjustments).

Are you suggesting a passenger car runs its own Linux distro?

According to Quora (last link in my reply above) the most common alternatives are Windows Embedded Automotive, a Linux derivative, and QNX. Why? To avoid writing millions of lines of fairly complex code on their own, of course. Just like a desktop developer saves a ton of work by writing on top of the OS rather than implementing their own OS from scratch.

If you include the underlying stack, then also my <body>Hello world</body> runs on tens of millions of lines of code.

Yes, but that's the point: The numbers for lines of code in a pacemaker or car includes the entire stack. If you want to compare it to web development, you'll need to include the full stack there too.

As a web/game developer, you forgot to include the OS and the drivers in the lines of code involved in executing the stuff you are writing.

The Linux kernel was 15M lines in 2013 [1], more than half of that was drivers. Windows XP was apparently 45M lines, the 2009 Debian distribution 300M lines [2].

So you're into millions of lines just to execute "Hello world" on a PC.

Simple control systems generally don't use an OS. E.g. Arduino is as simple as it gets, here [3] is a 30-LOC example snippet for a HTTP client. But if you dig down into the included libraries (most of it is on GitHub) you'll find that there's (quick estimate) 10-20k lines of code involved in executing those 30 lines. And you haven't actually _done_ anything yet, that's just the infrastructure to allow C code to interact with the hardware with a few standard libraries for math and IO.

Modern cars are complex enough to have OSes [4], with the corresponding code complexities.

In short, web developers vastly underestimate the code complexity of interacting with hardware in a low-level language because it's not something they deal with. The umpteen million lines of OS kernel and device drives are done by someone else, and for people who just _use_ a PC it (mostly) "just works", to the extent that even advanced users aren't aware of the complexity behind it.

[1] https://en.wikipedia.org/wiki/Linux_kernel#Codebase

[2] https://unix.stackexchange.com/questions/111281/exploding-am...

[3] https://www.arduino.cc/en/Tutorial/HttpClient

[4] https://www.quora.com/What-operating-systems-are-used-in-car...

iirc there were some studies showing that productivity is not significantly different across languages

If it's the same studies I'm thinking of, the result was that productivity was about the same in all languages _when measured in lines of code per day_.

So say 1k lines of assembler took the same time as 1k lines of Python. However, the higher level languages can _do_ more for the same number of lines.

Here's an architecture student who build his own small trailer home to have a place to live while studying: https://www.tu.no/artikler/na-har-sigurd-19-fatt-smart-strom...

(In Norwegian, but there are pictures and a diagram.)

In short: 130 sq.ft. trailer home, built with structural insulated panels on a boat trailer for around €30k in total. Bathroom, kitchen, sleeping area, room for four people. Google Sketch as design program. "Smart" control unit for electricity, e.g. it turns off the water heater when the electric stove is turned on, so the total power draw never exceeds the current limit where he's plugged in. And remote control from a smartphone app.

He built his own rather than buying a caravan because he wanted e.g. better insulation for winter use and full-size kitchen appliances.

Massive in extent, it covers large parts of the planet, and in duration, could last for weeks or months.

The threat to Opportunity isn't that the storm could rip it apart. It's that even a low-pressure wind can lift a lot of fine dust which blocks out the sun and leaves the rover without power from its solar panel. If it lasts too long the rover could literally freeze to death.

NASA has an image from another major storm in 2007 [1], it blocked 99% of the sunlight. This one is worse.[2]

[1] https://mars.nasa.gov/resources/7948/a-darkened-mars-sky/ [2] https://www.reddit.com/r/space/comments/8qvnrw/mars_rover_op...

Presumably the launch date, Intel lists launch dates for all of their processors on ark.intel.com [1]

5 years is Haswell, so Haswell and newer should get the microcode fix. A 3 year old computer is likely to have a CPU no more than 4 years old, but you can look it up to verify. (Both Windows and Linux can show the CPU model, and Intel's Ark site gives the release date.)

[1] https://ark.intel.com/products/series/75023/4th-Generation-I...

Hypothetical example pseudocode:

    if is_pointer(pt):
        // do pointer-based stuff
    else:
        raise error
If you train the branch predictor to expect a pointer, it will speculatively treat arbitrary values as pointers until it can determine that they are not. So you can pass in any value and get it treated like a pointer for the duration of the window of speculative execution.

Any conditional branch is potentially vulnerable, an attacker just needs some sort of side effect from speculative execution that persists after rollback.

Because when Pluto was discovered, they thought it was alone out there. Then they found that Pluto was a lot smaller than first thought (mass 1/5th of our Moon, roughly the size of Australia), and that there were a lot of other objects only slightly smaller in similar orbits (the Kuiper belt). And then we found Eris which is just as big as Pluto (slightly smaller in diameter, but more mass). So either they are all planets, potentially thousands of them in the Kuiper belt, or we redefine 'planet' so Pluto, Eris, and similar bodies are excluded.

So now a 'planet' is a) orbiting the Sun, b) mostly spherical, and c) mostly alone in its orbital neighborhood[1].

Pluto, Eris et. al are still more than mere rocks, they have been reclassified as dwarf planets[2].

It was a similar story with the asteroid belt: They found the first asteroid (Ceres, I think) and called it a planet. Then they found another, and another, and soon it became clear that there were a very large number of small bodies in similar orbits. So they decided that they weren't planets after all, and called them asteroids instead[3].

The difference with Pluto is just that it happened so recently.

[1] https://en.wikipedia.org/wiki/IAU_definition_of_planet

[2] https://en.wikipedia.org/wiki/Dwarf_planet#Dwarf_planets_and...

[3] https://en.wikipedia.org/wiki/Ceres_(dwarf_planet)#Classific...