skysight-inc/HackerNews huggingface dataset:
What about rejecting this inane trend toward home automation entirely?

In most homes you can realize 99% of the energy savings and convenience of a Nest thermostat with an $50 7-day programmable box. Set it up and forget it entirely; it should just blend into the background. I can't think of a situation it hasn't "handled" for me - my house is a reasonable temperature day and night, my gas bills are within the expected range. If perhaps I spend an hour cold or nobody enjoys an hour of produced warmth due to a routine change, it's not a big deal.

I cannot imagine wanting to check my thermostat remotely, or have it connect to the Internet, or _track my presence_ and presumably report it to third party data gathering monstrosities. To give up such a huge piece of information (to yet another company, assuming all the phone-related companies already know this...) without any real "payment" for it besides a self-adjusting thermostat strikes me as pretty mad - especially when I can't see any real reason why such a device even needs to be on the Internet at all to accomplish that.

Internet connected lightbulbs? Smart locks? Solutions waiting for problems, most of them badly built, insecure, and probably spying on you in multiple ways. More expensive than they should be, never really providing you much beyond the sort of creature comforts that a more capable person can safely disdain as being for the overly soft and comfortable set.

That said, I concur that using a local bus like this makes the most sense if you must do this, but consider what you're spending your money and your time on. I think a lot of this stems from some latent desire to simulate the James Bond / Ladies Man 70's vibe with the remote control that dims the lights, puts the Barry White on, and converts the couch into a bed. It's cheesy and your guests aren't as impressed as you think they are.
A large chunk of this page is related to simplifying ML stack installation. See the section on tensorman.
Ask HN: Why are private/hidden methods so popular in OOP APIs?
As a Python programmer, I heartily subscribe to the philosophy of "we're all consenting adults here" [0]. Nothing should really be private or hidden, because nothing is really stopping a canny user from cracking open your code and accessing that stuff anyway.

However, it seems like the opposite philosophy is the prevalent one, so I must ask why? Why do people inside on concealing and privatizing so much of their code, especially in open source projects where I can clearly see what they're doing?

Thanks.

[0]: https://mail.python.org/pipermail/tutor/2003-October/025932.html
I think goto in C with its labels, as a last resort where C's library of structured control flow constructs fail, is a much less bad thing than GOTO in BASIC with its line numbers and much more limited structured control flow.
That's an interesting question. Let's just say that I only remember colour when it's an important part of the dream.

As in: Am I driving through a red light or a green light? Is that dress that Charlene is buying specifically a green dress?
It depends. Many conversions are pretty well established these days (Like an LS into a Miata, or hell, an LS into just about ANYTHING) and there are off-the-shelf replacement wiring harnesses, ecus...
The Simpsons was never really that controversial was it? It's fairly family-friendly. Didn't have any bad language, almost zero sexuality, zero nudity, any violence is very cartoon, its satire is pretty gentle, plot-lines are usually wholesome in the end.
The economic (and environmental!) option is going to be not to do anything. You'd have to do hundreds of thousands of miles to make up the energy and materials in the new drive train.
No health insurance can deny insurance coverage for pre existing conditions since ACA was passed.
It’s also worth noting that in (north america? western societies?) many women (and certainly almost 100% of women using dating apps) are numbed by a nearly constant and pervasive onslaught of possible sex partners.
From that position then, they would never look for sex partners, they would simply choose to say yes the next time someone asks.
>I prefer the loops instead even if it means going down at individual elements in a list/matrix.

Actually you have it backwards, probably because you confused J's somewhat cryptic notation as the only way to implement the same concept.

It's the for loops, with their sprawl of non-declarative code, that would be equivalent to the regex opaqueness, and a well named operator or function to achieve the same thing that would be more like J.

E.g. would you rather use a:

sort(myList, order=desc)

or write your own sorting with for loops?

Similarly, think of operations like:

findElement(myList, predicate)

filterElements(myList, predicate)

keepElements(myList, predicate)

forEach(myList, myFunc)

forEachParallel(myList, myFunc, chunks=5)

In other words, reduce, map, and specialized versions of them.

If 10-20 such language provided functions covered all cases, I'd use them over for loops all the time. In fact that's how people use e.g. lodash.

What J adds is a succinct syntax to write and compose such primitives at the language level.

But such a syntax is not necessary to achieve the same concept (although not the same brevity/expressiveness) and be better/more readable than for loops...

P.S And regexes themselves should be compared to the equivalent parsing code -- which could require a FSM, or an ad-hoc buggy implementation of the same checks/captures spanning 10s or 100s of lines depending on the regex. Except if you just use a regex for very simple things where e.g. a "contains" function or some splitting etc will be simpler.
Problem: Messages Keep Saying “Warning: Message Encrypted” – WML Cloud
catalina safari
I switched from a Mac to a Thinkpad running Pop a bit over a year ago.

I miss the Mac trackpad and gestures. I miss the trackpad size and the surface itself. Wiring up libinput-gestures helps some things but you still don't get things like pinch to zoom in Chrome, for example, and the overall experience is not nearly as polished.

I miss Mac OS HiDPI support as well. Fractional scaling helps a bit, but switching from HiDPI to LoDPI and vice-versa (docking/undocking) can leave some apps scaled incorrectly, make a mess of your desktop, and I haven't been able to get a mixed configuration working where only my laptop monitor is scaled while my external display is not. I end up running this 1440p laptop screen at 1600x900 or 1920x1080 instead just to forgo the headache.

The VPN clients we use at work were much more pleasant to use on macOS. We have the option of using one of two different OpenVPN solutions as alternatives, and they're fine, but again, the polish isn't there (little things like automatically reconnecting to the VPN without my intervention would be nice).

I can't really think of anything else I'm really missing these days, though. Things I explicitly DON'T miss: Docker on Mac is a poor experience compared to natively running on Linux... Having a real Linux userspace by default is SO much more pleasant than dealing with Homebrew (which is great if you absolutely need it but I'm happier not having to deal with it at all anymore). I don't miss the Mac keyboard and touchbar. I don't miss troubleshooting things on macOS... it is incredibly opaque in comparison.

Overall, I don't think I'll be switching back any time soon, but would love to see more attention to the overall fit and finish as far as the desktop experience goes.
Who are you arguing with?
I think you need to clarify what you mean by "private". Are you referring to making methods private?

When you make a method public, you are making a promise to users that you won't make any breaking changes to that API without a major version upgrade. Once something is out there, you can't take it back. So if you have some functionality that isn't meant to be used by the outside world but is used to serve your API, then you wouldn't want to expose that and tie your hands in the future.
I think it makes sense to use whatever language you want, and the ideas in the book don't only apply to Scheme.

I've been working through the book in Javascript - https://github.com/ahuth/sicp/. Maybe I'm losing something by doing it in JS instead of Scheme, but I'm still learning a lot and having a ton of fun.

Wrote a little bit about SICP here: https://ahuth.github.io/articles/the-first-time-sicp-blew-my....
Or PCI-Passthrough which, while not as easy to set up as it should be, works amazingly well.
Because not all providers are contracted with your insurance. If there exists an agreement between your insurance and the provider (I.e. in network), then the insurance company does pay for everything beyond the out of pocket maximum.
The energy density of batteries isn't close to good enough. Small personal aircraft have a _very_ narrow weight allowance - and do remember the FAA mandates a minimum of 30 minutes of reserve fuel.
I get it. As an entrepreneur you get validation from customers, and you hold yourself accountable to them. The customer is the "authority".

To be honest this is one, of many, reasons I prefer to find and talk to customers before I even start to build a product. Having people you can talk to and run ideas past and get feedback from makes you focus on not disappointing them and giving you some feeling of needing to be accountable.

That all said, being an entrepreneur can be quite lonely and it is easy to get depressed, so you have to find ways to find balance for yourself and prevent it. I am actually reversed from you in that I find it actually easier being a founder than an employee, but in both cases you just need to find coping mechanisms that work for you.
Frankly, who cares?

It is fixable.

Just give it time and patience. Even if Purism doesn't fix it, folks outside of purism will help.

The fact that iOS (12 years) and Android (11 years) do things that are against your interests - that is unfixable.
>I honestly don't understand where you're coming from.

Perhaps they're coming from experience with better languages?

>Rolling your own error library is trivial.

And having to do so is a huge smell, if I ever smelt one...
I highly doubt it's tire tread if it was dry weather.

Turn-in is actually noticeably improved by lower tire tread on tires (as long as your tires are still roadworthy and the road is dry).

If you take a look at one of the most popular "sticky" tires for autocross, it almost looks like the tread has completely worn away on a normal tire: https://www.tirerack.com/images/videos/video_images_758x426/...

More likely they tried to get into the throttle during the turn at the wrong place, or tried to brake during the turn when caught off-guard, both of which would upset the balance of the car and send you off the road.

Traction control (or intentional chassis/suspension design) might have saved them from oversteering (spinning out towards the road), but not been able to prevent them from going off the road
I really like their checklist. It brought many details to my attention that I would have missed when developing such a feature. Does anyone know such a list of checklist (awesome-checklists or so)?
A distribution like Ubuntu, Debian, Pop!_OS, Fedora, etc., is a collection of programs from many, many other projects and places. Almost every distribution configures things a slightly different way, but almost any other distribution can be configured that same way.

Distros include a unique set of packages, but after installation you can remove what you don't want and add what you do.

The single biggest factor in terms of sheer compatibility with your hardware is the Linux kernel, and every distribution has one. Some are older than others. Some projects remove things from the kernel and recompile. Others add things.

But by and large, the Linux kernel is the same from distro to distro. Some ship newer kernels, to be sure, and some ship older ones. The Linux kernel developers maintain a few different kernels at the same time, some older with security patches, some newer with the latest features and drivers.

Fedora ships new kernels all the time. If you have new hardware and have parts that are not working so great, new kernels will often solve your problems. It's not the distributions doing this, it's the kernel team.

If you have old, stable hardware that works great with an old kernel, you might want to run something like Debian or CentOS -- if you like that sort of thing.

Fedora or Arch are both great ways to get new hardware working its best, but that's because the Linux kernel developers are doing this work at the kernel level, and these distributions pick up new kernels very soon after they are released.

If distro developers contribute back to the Linux kernel -- and many do, from Ubuntu and Fedora for sure, but for others, too -- everybody benefits from those improvements when a new kernel is released for the use of all distributions that want to package it.
It's easy to say there should be a physical connect/disconnect for audio or video recording, but how do you enforce that it is designed as a complete barrier?

I'm thinking of Nevada regulations on casino equipment...
> Its stupid on their part that they sold the car to him without release from any potential liability if he crashes the car or injures himself and others, like in this case.

It boggles me that anyone would have any expectation that the seller of a high performance car would be liable for the driver crashing it. It’s not like they didn’t know it was a beast of a car. What happened to personal responsibility?
Firstly, late binding is orthogonal to inheritance. It simply means that methods are looked up based on runtime information, rather than determined at compile time. You can have late binding in a language with no inheritance or classes at all.

Secondly, OO composition does not solve the problem I described in #3. If object X has 9 methods I want to reuse in object Y, making X a component of Y still requires me to re-implement those 9 methods in Y, even if they are just pass-throughs.
I felt the same way but I love it these days, I just used it wrong for a long time. It's very opinionated and you kind of have to adjust to the workflow. It makes more sense to treat it more like a tiling window manager than a traditional UI and use the keyboard extensively.

I've reconfigured switching between workspaces to simpler hotkeys and together with the overview you can keep a lot of stuff open and navigate without things feeling cluttered.
The more public interfaces you have, the harder it is to improve things.
Hehe.

It's interesting to think about these:

* unicode -- I think the naysayers would win here because there are way more people today who understand the security and complexity issues surrounding the topic than those who understand the details of why unicode and the various encodings work the way they do

* gnu -- this would be a great challenge to the naysayers. But I think it could be done if the naysayers really studied the hardware of the time and could ask pointed questions that a Stallman impersonator couldn't answer.

* fftw - "hey we're gonna build a library that queries at runtime for whatever SIMD instructions are available on the user's computer and choose the fastest algo." Yeah right. :)

The possibilities are bounded but many.
Batteries are DC. Transformers are AC. AC-DC converters are bulky.
Any tips for improving the general trackpad experience with lip-input?

Recently started running arch on an X1 carbon and wondering what I can do to make the trackpad better.
This is a great list. I would add six more:

* Requires a computer with <OS list> to function

* Requires that software be installed from <list of app stores>

* Device data format is documented

* Deivce software can be replaced with independently developed software, but might require NDA or other agreement with the company

* Device software can be replaced independent of the company, but might might require NDA or other agreement with a third party (chip maker, etc.)

* Hardware is fully documented
Most hardware these day is designed for Linux first, then ported to Windows. Linux has a dominant market share in servers, IoT and mobile. While the Android kernel (and it's "drivers") isn't really Linux anymore, it usually doesn't matter much. The driver will exist and they will be implemented by the manufacturer (most of the time) or RedHat/IBM. If a chip (like wireless) has any use outside of laptops, then it's going to have some kind of support.

Lenovo, Dell, Huawei and HP sell laptops with Linux pre-installed and supported.
I'm not sure why you would think that your phone is 100% off when it's "off". PCs have had an "always on" secondary processor and OS[1] for years now that runs whenever there is power, and you can't remove the battery in most phones, can you?

[1]https://en.wikipedia.org/wiki/Intel_Management_Engine
Why does pain seem to underlie all sickness?

Inflammation is likewise usually a symptom, not the cause. And in the case of muscular injuries, it is generally helpful to the healing process.

The kind of imbalance mentioned in the article isn't really a culprit in most instances of sickness.
Pennsylvania debating $250 annual electric vehicle tax
>That's bad Go design.

I think that's the parent's point.

Though, not that that is bad Go API design on behalf of the library authors (as you imply), but that that is a sign of Go's own bad design -- the fact that it leaves it to programmers own devices to get their API design right with respect to errors...
You could do more! Use Array.map and Function.apply via interop and you seem to have it all in JS
Wow, that's a great addition, I will update the post. Never even thought about these. Ok done. I merged two of your points and added yet another one.
It totally was controversial in the beginning. It was considered worse than South Park or Family Guy are today. George H.W. Bush (the father) even made a statement that the American family should be "more like The Waltons and less like The Simpsons." ("The Waltons" was a series about a wholesome family in Virginia surviving the Great Depression)
Probably panicked and locked up the brakes. Most cars (even sports cars) are set up to understeer unless really provoked, on the basis that a frontal crash is safer than hitting something sideways.
Disclosure: I work on Google Cloud.

The blog post doesn’t make it as direct, but one of their biggest costs was for networking between datacenters (Availability Zones in AWS). Most comparisons for “buy a rack at a colo” assume one colo, and a static fleet of hardware.

If you wanted to compare apples-to-apples, you’d need to have (at least) three nearby colos with enough capacity to handle one going down entirely at peak load (“N+1”). Leased lines in a metro area aren’t actually all that expensive, but like the compute, you also need to purchase that with failure in mind.

tl;dr: Maybe, but the analysis needs to assume the same(ish) reliability outcome. Otherwise, they could have avoided lots of cost by just running in a single Zone.
It’s not clear at all. I think we’d instead select against undesirable traits. If intelligence and fitness are too varied to select for we could select against lack of intelligence or lack of physical fitness. Say I’ve had cancer at a young age I’m out but we can’t decide on body type. I can’t even imagine how to avoid antisocial behavior, which is fine since any attempt at this Is dystopian.
You would do what Reagent does and use JS interop yourself and call React directly. Plenty of people in Clojure-land implement things themselves if the thing to implement seems simple enough. Probably more true for Clojure developers than let's say JS/Ruby developers.
Another way of phrasing it is that a public interface is a kind of tight coupling. Also, private methods are typically contain highly factored code which may have little utility outside of the interface but which is factored for reasons of modularity.
> But it's still just syntactic sugar, the neater code just masks the underlying code that contains the actual loops and conditionals.

It seemed to me that was often more performant than using a loop.
Yeah, I think the local control argument would be quite effective against a number of technologies.

In fact Linux mailing list comes standard with its own early argument from Tannenbaum against the monolithic design. So no alternate history necessary there. :)
Great project, but adjacent punctuation hurts me
Association does not imply causation either. Your entire argument is simply association. You say soldiers and then you associate war; you say war and then you associate power; you say power and then you associate sex. What you are not being plain about is that you choose each association. You could have chosen another; there is no reason offered for why we have to consider this particular chain of associations.

This is how so much psychoanalysis worked, by the way, and is part of why that school lost credibility.

Your final point, turning the commenters argument around on itself, is a masterful example of rhetoric but not of argument or explanation. Of course, you leave open the question of why sex is important to us; of what it draws its importance from.
I get what you’re saying in terms of Photoshop and Illustrator, but what about After Effects (and by extension Adobe Media Encoder)? I love web tech, but I have never seen an application come close to the power I get in there.
I mean, aren't potatoes basically a carbohydrate gel?
Lol...so a cyclist is supposed to eat a raw potato while cycling instead of something easy to eat like a gel? ok.
I find that most programming languages are often wasting time on the notion of plurals .. loopless sounds appealing there.
Pricing: my calculations are currently at $30/month per user, at 8hr/day usage with this instance sizing. I'll double-check the sources I used to get pricing.

Medium instances would be appropriate for IDE use cases. I upped to 2xl to handle 3D design tools, but with the recent interest out of the developer community, I can readjust myself downward from 2xl to medium or large.

You get cut off every 6 hours (instance spins down automatically based on your plan). Immediately, you can spin it back up and reconnect for another 6 hrs. The same applies to the free tier, at a 1 hr cap.
In lots of organizations sets of metrics aren't "held in tension" and that causes all sorts of wild problems. As a trivial example say you want to stop people from quitting your app. Easy! Just lower the price by 50%. So we often have to set metrics while satisfying all the other constraints. This is the #1 thing I've seen go wrong when teams try to use OKRs or some other metrics based activity; they fail to figure out the related components and either hold those in place or improve them along side their initial goals.