mikaraento

Things that have helped me:

- nose mask rather than full face mask

- nasal spray if my nose feels congested

- upping the pressure. In theory a professional is supposed to set your pressure but I do tweak mine. If the setting is not visible it's probably in a hidden menu - Google for how to enable it for your machine.

- sleeping pills

I hope you find a solution. Sleep apnea is terrible.

To be fair, in the case of hearing aids you are both in the right.

Excessive regulation has created oligopolies and kept prices high in the US. The OTC hearing aid category is meant to help. Before that, low-cost devices tended to remain niche.

OTOH the regulation(s) were introduced due to blatant sales of substandard devices, esp in the 1970s. A high-amplification device runs the risk of further damaging your hearing. Many hearing aid users are vulnerable elderly.

There was a influential internal white paper about not being a "tech island" that drove open-sourcing. The point was that by having its own tech stack Google would eventually be left behind and have a harder time recruiting.

Not sure if the message is still believed as strongly.

(Some) TPUs look more like those non-shared memory systems. The TPU has compute tiles with local memory and the program needs to deal with data transfer. However, the heavy lifting is left to the compiler, rather than the programmer.

Some TPUs are also structured around fixed dataflow (systolic arrays for matrix multiplication).

Indeed, this happened with Symbian. An IPC server could panic the client. As an application developer without access to the OS source code this was pretty terrible. Not all preconditions were easily understood and could vary between devices and OS versions.

GPS signal disturbancecs are surprisingly common: https://gpsjam.org/

While C3 might not be strong evidence against XP neither should it be considered evidence _for_ XP.

On newer planes both of them often are

I used to be like that. Cooking in milk instead of water made the difference for me.

I use regular rolled oats with 2 parts milk, 2 parts water and 1 part heavy cream.

You are correct about SELinux in general terms.

However, there is a large scale exception to this: Android. Android uses SELinux extensively, and it is also used as part of further sandboxes in Chrome and Android System Intelligence.

We've shared some plans for client-side inference (TFLite) support in https://www.w3.org/2022/11/17-webmachinelearning-minutes.htm.... The presentation was for WebML but mentions non-WebML work. It's not shipping yet though.

(I work for Google and I work on client-side StableHLO, but I don't speak for Google).

It's used for several ML-related projects, including as the model format for TensorFlow Lite (TFLite). The TFLite format also has long-term support as part of Google Play Services. The main attraction is ability to pass large amounts of data without having to serialize/deserialize all of it to access fields.

(I work for Google but don't speak for it.)

Korppu (hard cracker/bread) and lerppu (floppy) in 80s-90s Finland :)

I don't understand the difference between in-ear monitors and hearing aids well enough to give a reasoned counter-argument to that.

However, Costco does sell hearing aids for 400-1000 USD while audiologists sell mostly comparable equipment for 3000-10000 USD. So there is definitely pricing power in the current setup.

Most people in the industry also expect lower price devices to come to the market when the bar to entry becomes lower and manufacturers can start experimenting with new size/form factor/battery/functionality combinations. For example Bose Hearphones were selling at 500 USD as a low-volume product without much competition.

Would you have a pointer to the 20% number? I'm genuinely interested in learning more.

IIRC the overall prevalence of hearing loss is has not been changing that much. There are a couple of opposing forces at the population level.

Most common hearing loss is age-related and the population is getting older.

Two other common causes are exposure to loud noises at work and infections. Work-related exposure is decreasing as fewer people work in heavy industry and hearing protection has become almost universal. Infections have also decreased with better hygiene and health care.

I don't know of evidence that loud music is actually causing hearing loss in young people.

Before the new OTC regulations, the situation in the US has indeed been confusing in multiple ways. This has lead to consumers mostly perceiving hearing aids as prescription devices and the industry being able to maintain higher prices because of that.

On the federal level the FDA has required that buyers provide a medical assessment stating their need for a hearing aid. However, buyers older than 18 have been allowed to waive that requirement.

On the state level, many states have had prescription requirements. The FDA has ruled against such state laws several times but many laws have remained on the books. While in theory unenforceable, they have created a lot of FUD for prospective sellers.

The industry (audiologists and hearing aid manufacturers) has continuously reinforced the view that prescriptions are needed and in the buyers' interest.

Personally, I do think the new OTC regulations make the situation clearer and have the potential to improve products (assuming products become easier for users to configure themselves) and lower prices (as it's not only the audiologist's service buyers have paid for, but bundling of examination+device+followups has allowed higher pricing for the devices as well).

(See https://www.audiologypractices.org/state-laws-and-hearing-ai... and https://fda.report/media/75418/Regulatory-Requirements-for-H...)

ML Kit only runs on devices with Play Services, sorry.

We do offer an official SDK that does that, see https://developers.google.com/ml-kit/language/translation

(I work for Google but do not speak for it)

Google also provides an official on-device translation SDK that is free-as-in-beer (https://developers.google.com/ml-kit/language/translation).

The models are around 20M for any single language so there is a not insignificant cost on the user in terms of delay for downloading, data usage and disk space.

Disclaimer: I work for Google and worked on the ML Kit Translate SDK, but I don't speak for Google.

ffmpeg/libav is being fuzzed with reasonable success. See for example https://github.com/google/oss-fuzz/tree/master/projects/ffmp... and https://security.googleblog.com/2014/01/ffmpeg-and-thousand-....

They found issues in code I wrote...

(I work for Google but do not speak for it)

FWIW, I created a production batch transcoding backend using python to construct ffmpeg command lines. If you don't need streaming you may not need to talk to the libraries.

(The transcoding was for transforming DVB-T captures to multi-bitrate HLS and MS Smooth Streaming formats as part of a Cloud PVR. It was a separate backup pipeline in case the commercial streaming pipeline failed, which tended to happen a lot initially.)

That is pretty much how macros worked in Excel 4.

This is very true.

However, it's likely to be correlation rather can causation. Loving parents pass on loving genes.

I recommend Judith Rich Harris's book "The Nurture Assumption" on the topic. (https://en.wikipedia.org/wiki/The_Nurture_Assumption)

Eliyahu M. Goldratt

And yes, everybody should read it.

Scheduling is one of these areas where the core problem is quite well-defined, but the devil is in the details - both static and dynamic. Bit like one module of ERP.

Static details include things like local labour laws, skill constraints, unions etc.

Dynamic details include things like allowing employees to state preferences, swap shifts (while respecting labour laws), call in sick etc. without having to reshuffle everything.

There probably are quite a few submarkets (geographies/industries/sizes) that don't have tools; whether you can make money is a different question.

Full disclosure: I work for Google and like it

I left Google in 2009, quite unhappy about the difference between a startup and corporate politics. After that I worked at 3 startups (5 years), 1 telco (1 year) and at McKinsey (3 years).

I ended up interviewing at Google again in 2018, after deciding that a) I liked programming more than management consulting and b) my comparative advantage was in programming. I definitely could have felt entitled after 1) passing Google interviews once before, 2) having had three somewhat successful startups and 3) proving I can also handle the corporate side.

I was asked multiple questions that could be interpreted as 'algorithmic' (and I have to admit that after 3 years of not coding I was nervous about them). However, they can also be interpreted differently, more charitably. They all followed the structure of: 1) give a reasonable but not completely defined problem - you should be able to clarify enough of this to show you can deal with some ambiguity; 2) turn that into an algorithm - you should be able to articulate an easy algorithm and be able to discuss improvements to it; 3) turn your algorithm into code - you need to show you can actually program. I definitely didn't have to memorize and regurgitate textbook solutions.

I acknowledge that a) the above may optimize for rejecting all negatives at the cost of some false positives and b) it's still a very basic lower bar and doesn't predict who will perform highly vs. ok. However, I did think it tested for the core skills I expect from programmers.

I've also set up interviewing processes at startups. I did end up emphasizing ownership and 'getting things done' more than Google does. I do think startups should test for different attributes than 100k+ FTE corporations.

I can confirm this from personal experience (at least it was the case 10 years ago).

McKinsey tests for something like this through a structured probing of past actions. I always felt we did a reasonably good job of discovering evidence of such skills.