sholladay

A lot of the techniques that both sides use would be much harder on macOS. Of course, Hackintoshes have always existed and where there’s a will, there’s a way. But it makes me wonder how this would evolve if Apple eventually gets its act together and makes a real push into gaming.

Yes, but a computer is just a paperweight without its software. Also, increasingly the hardware is being specifically designed and optimized for that non-deterministic software. The experience of using computers is changing and we’re still in the early days of that shift.

Of course there’s still plenty of deterministic software you can run… for now.

This is a great algorithm!

In this era where AI is eating away at how deterministic computers are, I really appreciate reading about an elegant solution to a real problem using deterministic logic.

I assume that the inclusion of some AI generated content is ok, such as when discussing the performance of different models?

0.3Wh for the median ChatGPT query seems optimistic to me. It looks like it’s based on a quote from Sam Altman.

The GPU alone is probably pulling close to 0.2Wh per second.

You are absolutely right.

Here is why you are correct:

- I see what you did there.

- You are always right.

As a maintainer on the Ky team, I give a big thumbs up to this proposal.

We have run into many problems with web streams over the years and solving them has always proven to be hairy, including the unbounded memory growth from response.clone().

The Deno team implemented a stream API inspired by Go, which I was happy with, until they ultimately acquiesced to web streams.

This proposal shares some of those principles as well.

As a passenger, I often think to myself, "Why is the bus stopping here? There was a a stop just two blocks ago." Invariably, the bus then has to wait for someone to move out of the way before it can pull in. It's very inefficient. Stops should be about 10 walking minutes apart at minimum.

I think you’re confusing “haptic” for “capacitive”. The wheels are real, physical controls with motors to give tactile feedback about the state of the UI. You can literally feel where the beginning and end of a list are, for example. It’s even better than traditional buttons.

The only problem is that there aren’t also physical controls for media and climate, which there should be. But for everything else, the thumb wheels are going to be awesome.

So we are finally building the Rods from God

https://en.wikipedia.org/wiki/Kinetic_bombardment

Why? What do you prefer to do instead?

Maintainer on the Ky library team here, a popular HTTP client for JavaScript.

We support these headers, but unfortunately there’s a mess of different implementations out there. The names aren’t consistent. The number/date formats aren’t consistent. We occasionally discover new edge cases. The standard is very late to the party. Of course, better late than never. I just hope it can actually gain traction given the inertia of some incompatible implementations.

If you are designing an API, I strongly recommend using `Retry-After` for as long as you can get away with it and only implementing the rate limit headers when it really becomes necessary. Good clients will add jitter and exponential backoff to prevent the thundering herd problem.

Personally, I like that UTC is the default time zone. Processing of dates should happen in a standardized time zone. It’s only when you want to display it that the date should become local.

I started looking at self-hosting many applications at home once I realized that IPv6 could enable me to do that securely without any complicated router/firewall configuration that would need to be maintained.

The only wrinkle I ran into is that apparently ISPs are still reluctant to give out static IPv6 prefixes to residential customers. So you still need some kind of DDNS setup, which is lame.

When people say “creator’s intent”, it sounds like a flavor. Like how food comes out of the kitchen before you put toppings on it to make it your own.

But vivid mode (et al) literally loses information. When the TV tries to make everything look vibrant, it’s effectively squishing all of the colors into a smaller color space. You may not be able to even tell two distinct objects apart because everything is similarly bright and vibrant.

Same with audio. The famous “smile” EQ can cause some instruments to disappear, such as woodwinds.

At the end of the day, media is for enjoyment and much of it is subjective, so fine do what you need to do to be happy. But few people would deliberately choose lower resolution (except maybe for nostalgia), which is what a lot of the fancy settings end up doing.

Get a calibration if you can, or use Filmmaker Mode. The latter will make the TV relatively dark, but there’s usually a way to adjust it or copy its settings and then boost the brightness in a Custom mode, which is still a big improvement over default settings from the default mode.

I have a Samsung SlimFit HD tube TV from 2005 or so. It’s such an interesting piece of retro tech because it is widescreen, supports 1080i, and has HDMI, but it is a CRT! It’s also quite a bit thinner than most tubes. Super unusual.

I got it because LCDs always looked terrible to me and plasmas were still very expensive.

https://www.crutchfield.com/S-WXftqFAhnMu/p_305TXR3079/Samsu...

I’m only aware of two times that Apple has revoked certificates for apps distributed outside of the App Store. One was for Facebook’s Research App. The other was for Google’s Screenwise Meter. Both apps were basically spyware for young teens.

In each case, Apple revoked the enterprise certificate for the company, which caused a lot of internal fallout beyond just the offending app, because internal tools were distributed the same way.

Something may have changed, though, because I see Screenwise Meter listed on the App Store for iOS.

https://www.wired.com/story/facebook-research-app-root-certi...

https://www.eff.org/deeplinks/2019/02/google-screenwise-unwi...

This sounds like a really good excuse to not bear any responsibility for anything other than what you want to work on. PR reviews will mean nothing; they will all be rubber stamps or style nits because no one else will understand the code other than the owner. Your bus factor will be crazy low.

Collaboration sucks because of the way it is done, not because it has to. Pointless meetings for decision making that should be async. Brainstorming over Slack when that's what a meeting is actually good for. Looping people in to collaborate at the end instead of at the beginning. This is all possible to fix.

What I do is have everyone work in pairs. Pairs are small enough that communication is easy and there's no design-by-committee. But there's always someone to have your back and help when you get stuck or bogged down (e.g. decision fatigue), which happens plenty even to senior engineers. The pair starts and finishes work together, which mostly eliminates the need to loop someone else in randomly and needing to explain the thinking and background context, because they can bounce ideas off of each other and leverage each other's different areas of expertise. Whatever the end result is of that collaboration is treated as a finished unit of work, it's already been looked at closely by two people, it doesn't need a complicated approval process. The automated tests run, the release manager looks for any obvious mistakes, and then it ships.

The hardest nut to crack is the "who is the driver and who is the navigator" problem. I find that it is best to leave that up to the pair to work out for themselves, since it depends on the personalities involved. But with some guidance to not step on each other's toes. Working on the same line of code at the same time constantly is clearly the "too much collaboration" extreme that the article's author dreads. It's better if one person designs while the other codes, or one works on the logic while the other does the TypeScript types, etc. Usually the pair struggles with this for a week or two and then they develop a groove and it's rarely a problem after that. Spontaneous or infrequent collaborators never reach that groove, hence it can be inefficient and frustrating. Long-term pairs get to know each other and then work fast and smooth.

If someone else steals your work, you should be proud. They found it to be valuable. If they managed to sell it or build something with it, they’ve demonstrated that you can do the same. Use it as a learning experience.

Keep in mind that you are in control of what people are allowed to do with your software. By default, your code is unlicensed even if it is public, which means no one else can distribute it or change it or do much of anything with it. Thus, if someone uses it and claims it to be theirs, you can sue them if you want to.

However, instead of leaving your code unlicensed, I would recommend choosing an open source license and applying it to your code when you make it public. There are many to choose from!

By applying a license to your code, you are establishing a clear framework for what other people are and aren’t allowed to do with it. And it’s legally enforceable. In fact, there are organizations that may step in to help you if someone violates your license or challenges it in court. For example, my preferred license is the Mozilla Public License. If someone tried to challenge me on any part of that license, Mozilla would have a vested interest in defending it, since it’s their license and they use it, too. Their lawyer is even available to chat with over email. I once reached out to ask if I could make a small tweak to the license without causing headaches. They got back to me within a few days and said it would be fine. That gave me a lot of confidence to continue using it.

Some licenses are very permissive, such as MIT. Others are much more restrictive, such as GPL. The MPL, which I use, is somewhere in between.

What’s right for you really just depends on what you consider to be fair. And every project can be different. Maybe you build some small tools that you release under MIT, essentially donating them to all of humanity. Meanwhile, you create a startup and build a product where you keep some of it private and release parts of it publicly, licensed under the GPL, because you don’t want huge corporations stealing the work for your day job without reciprocating. That’s a relatively common approach.

Whatever you decide, just make some of your code public. The feedback and experience will be well worth it. Good luck!

I think the main thing holding people back from leaving the cloud is simple inertia. There was a time when the cloud was obviously the right choice. Static IPv4 addresses were becoming scarce, IPv6 had not been deployed widely enough, and cloud providers made it easy to stand up a server and some storage with high speed links on the cheap. But over time, things have changed. Rate limits, data caps, and egress fees are now normal (and costly). IPv6 is now deployed widely enough that you might be willing to just run an IPv6-only stack, which greatly simplifies running a server on-premise. And of course, we've all seen time and again how providers will carelessly lock out your cloud account for arbitrary reasons with little to no recourse. The time has come to own your infrastructure again. But that won't happen until people realize it's easy to do.

Star Trek has a number of organic computing examples, too. Species 8472, Data, and the Borg all use varying degrees of organic components.

There's also the bio-neural gel packs on Voyager and the unnamed 31st century Earth vessel discovered by Archer and the NX-01 Enterprise.

New Trek even has a mycelial network in space.

Some time ago, there was a project called Citizendium that aimed for quality over quantity, with articles written and peer-reviewed by subject matter experts who had to use their real names and working email addresses, among other requirements. I always thought that was interesting, since the main critique of Wikipedia is its open editing model.

Citizendium is still around, though they've loosened some of the requirements in order to encourage more contributions, which seems self-defeating to me. I think they should have tried to cooperate with Wikipedia instead. The edits and opinions of subject matter experts could be a special layer on top of existing Wikipedia articles. Maybe there could be a link for various experts with highlights of sections they have peer-reviewed and a diff of what they would change about the article if those changes haven't been accepted. There could also be labels for how much expert consensus and trust there is on a given snapshot of an article or how frozen the article should be based on consensus and evidence provided by the experts. This would help users delineate whether an article contains a lot of common knowledge or whether it's more speculative or controversial.

This is why you should:

- Write functional tests, not unit tests

- Not use compilers or other systems that do a lot of black magic (like changing the type signature of your functions (!))

Props to you for taking the time to test with a screen reader, as opposed to simply reading about best practices. Not enough people do this. Each screen reader does things a bit differently, so testing real behavior is important. It's also worth noting that a lot of alternative input/output devices use the same screen reader protocols, so it's not only blind people you are helping, but anyone with a non-traditional setup.

Navigation should come early in document and tab order. Screen readers have shortcuts for quickly jumping around the page and skipping things. It's a normal part of the user experience. Some screen readers and settings de-prioritize navigation elements in favor of reading headings quickly, so if you don't hear the navigation right away, it's not necessarily a bug, and there's a shortcut to get to it. The most important thing to test is whether the screen reader says what you expect it to for dynamic and complex components, such as buttons and forms, e.g. does it communicate progress, errors, and success? It's usually pretty easy to implement, but this is where many apps mess up.

Obviously you should set standards for your company. I’m not saying just hire anyone and be done with it. But I am saying that hiring is a long-term project. And I am saying that many people could meet your standards if you meet them half-way by giving them all of the information they need, holding their hand a bit at the beginning, and giving them time to figure everything out.

I’ve worked at places that have the opposite philosophy - hire quickly and fire quickly. That works in terms of hiring people who already happen to be what you want them to be. It just leaves no room for anyone who could be, but isn’t yet, what you want them to be. It also leaves no room for anyone who is different from what you are looking for but who could still bring a lot to the table if you just take the time to figure out what that is, which I think describes a lot of people. You might have hired a mediocre programmer who would be a rockstar at documentation, for example. That kind of thing happens all the time, yet workplace culture and practices tend not to accommodate that. By all means have standards, but put in some effort to help your people reach them in their own way.

Monocultures can avoid stagnating if they occasionally accept fresh blood from the outside. But hardline stances don’t allow for that. My point is, even if you only want to work with the best of the best, and you’re willing to ignore underprivileged groups with tons of potential, you still need an on-ramp if you want it to be sustainable.

The great engineers don’t graduate from college knowing everything they need to know, nor are they born with that knowledge. It takes time and help from other people to get them there. Even if they were already a top performing engineer at Netflix, that doesn’t mean they can smoothly transition into a role at your company and perform well with zero assistance. The on-ramp matters and has a huge impact on how they will perform. Some people will require more investment than others, but that’s true regardless of whether you stubbornly try to maintain your existing monoculture. And I firmly believe that everyone brings something different to the table. It’s mostly a matter of figuring out what that is for each person.

It’s the largest residential model that Ecoer makes. The home is a 3-bedroom, large but nothing crazy. The installers said they erred on the side of too big, rather than too small, and that’s corroborated by my back-of-the-napkin math and Google searches indicating that “too big” is standard practice in the HVAC industry. So in theory, it shouldn’t be a lack of power. I think it’s poorly optimized. From what I’ve been reading, the pressure in the lines is very important. I have no idea if they are pressurized properly. The unit apparently has sophisticated monitoring of the line pressure, but the IoT gateway has no end-user access which is a huge red flag for me that I wasn’t aware of before it was installed.

I always preferred to use sanitize.css, which is the same thing except it also makes sure everything looks pretty good.

https://csstools.github.io/sanitize.css/

We had a heat pump installed last year. It’s advertised as a cold-climate heat pump and it’s “good enough” for us, but it’ll never again be toasty on a cold night, just relatively warm. When under heavy load, it also has some kind of loud vibration issue, I think in the lines that run from inside out to the condenser. The system is an Ecoer, which is a Chinese company that pretends to be a U.S. company. And it has a really suspicious 4G cellular IoT modem that, of course, feeds all the data to their cloud, with no end-user access.

I will say, it keeps the temperature very stable, which is nice. And it saves money, paying for itself within 10 years. But there’s actually quite a bit that can go wrong during installation and it’s not easy to get them to fix everything, maybe because U.S. installers aren’t used to all of the nuances of heat pumps yet. Our aux heat strips still aren’t working properly, after multiple service visits.

If I could do it over again, I would still get a heat pump. But I would go with a Mitsubishi system and a more experienced installer. The extra cost is worth it.

Your logic could be sound if the lowest rung of the skill ladder was simply inevitable for everyone who is currently there. But that is wrong and, really, makes no sense. Many people are just young and need to be trained. Others were taught bad practices and need to be re-trained. Still others have their priorities wrong, but could do good work if they were given a reason to care about the right things. It also takes time for people to grow and to change and to learn from their mistakes.

If you take a hardline attitude on keeping the gates up, you're just going to end up with a monoculture that stagnates.