skysight-inc/HackerNews huggingface dataset:
I really love small neural networks. They have some nice properties that people overlook. The training speed record (warning, self promo) for CIFAR10 to 94% uses a very tiny neural network (<10 MB if just saved raw out to disk as a definition file). That's located at https://github.com/tysam-code/hlb-CIFAR10.

You could make that even smaller if you wanted to, though at least this network is already pushing maybe even a little further down the diminishing returns spectrum in some areas than I'd like, I suspect (bound by the powers of 2/multiples of 8/multiples of 64 required by GPUs :'(((( ).

I think a really fun future challenge (yes, I know, this is taking us back to the 90's-2000's in terms of challenge territory, but I believe it has much more practical use than a lot of other modern day benchmarks) would be to find the fastest-training network that infers at 94% in under 1 MB. I certainly believe it's possible, but with pareto laws the way they are, it would take a whole lot longer to train and might not be as fast on a GPU during inference as the main net (despite having fewer parameters). That might not be true, however.

There's a few NP-hard problems that actually exist in this space that not a lot of people talk about but I feel will be considered a core part of the theory of training neural networks at some point in the future. The size of the network is a very interesting tradeoff that opens up certain mathematically interesting properties on either end of the spectrum. Bigger is not always better, though it is simpler and simple oftentimes survives, especially (especially especially especially) when skilled technical workers in a very particular niche live in the shallow long tail of [insert correct distribution of skills rarity here].

One of the common threads (might be a "common", I'm not sure to be honest as I live in my own personal bubble of research interests and community and etc) is the dimensionality of the problem at hand. That plays into the scale of the network used to solve a problem. I remember some discussion being sparked a while back from some Uber research about the inherent dimensionality of a particular problem for some given particular neural network (though of course it's naturally linked to your inductive bias so please take that as you will). As you noted, some networks do quite well with very few neurons, 15 is a record however from what I've heard (and I'd love to see that -- I have a guess as to which particular method, or, at least, method family, it is... ;P I'm...casually interested in that arena of research).

In any case, as you can see I am quite interested and passionate about this topic and am happy to discuss it at length further.
If you end up having to scan the 10 GB graph many times per query without acceleration structures helping you (like indices), it will be slow. I'd say it's still a DB problem.
I think JSON syntax is more prone to user syntax errors. And we are talking about syntax errors by the kind of user that neither knows what a "syntax error" nor "JSON" is.

Hence the "O" in "TOML" ("Obvious"). And this is the use case for TOML, simple user facing configuration that they are very likely to just get right.

JSON is fine for more intricate data structures or very complex configuration, but if you just need them to enter a few numbers and booleans it is overkill.
> While this was a shock in the moment, I would later learn that this attitude was fairly common among Rails developers at the time who were largely encouraged to treat their database as a dumb data store by convention and to let the application do the work.

This is not a bad attitude depending on specifically what levels of "dumbness" you mean. IMHO, the golden rules for database setup are:

- Spend a lot of time designing your schema. Then spend some more time.

- Do not skimp on data integrity measures like proper primary/foreign keys

- Pay attention to potential usage patterns and build indices for performance; this is not a one-time activity, keep observing the usage and look out for hot-spots

Some other tangential points that are often overlooked:

- Do not push all your business logic into a hairball of nested stored procs and triggers; debugging/testing all that is a bitch compared to writing unit/integration tests or dropping into debugger in an IDE. You can be a million times more expressive in a full-featured modern language like Java or C# etc. The main exception to this is when you need to push/transform tons of data around and all of it is on the database - a well tuned stored proc would be orders of magnitude faster. This is also not something is needed frequently and could be symptomatic of a bigger issue.

- Tons of database trips are expensive; an efficient join instead can do wonders for the performance. If you are doing that all the time, maybe its time to put that behind a view. Also, cache what you can and be conservative about it.

- If you are almost always including a filter clause in all your joins, maybe you can explore partitioning.

Basically imagine the database like an appliance that does only a few things but those things are FUNDAMENTAL so we ensure that it does them very very well. Don't make it make your coffee too (though PostgreSQL probably can do even that efficiently).

> There were other factors too, such as depending on Rails to validate uniqueness rather than the database. It resulted in a lot of messy data cleanup that I had to deal with which were causing hard to diagnose issues because race conditions will always happen.

> Second, the database is the only place that can make guarantees about data integrity so use them.

Thats what I meant.
> I keep them because I know none of the file / video / music streaming services can be trusted.

That's not an emotional attachment, that's just practical. My kids are going to be like "Neil Young? Sorry, never heard of him" because he pulled his music off Spotify -- a blunder that lies somewhere in the space between a disservice to future generations and an "own goal".
You can always pass the async executor to the sync code and spawn async coroutines into it. And you can keep it in a global context as well to avoid parameters. E.g. there is `Handle::current()` for exactly this purpose in Tokio. Function coloring is just a theoretical disadvantage - people like to bring it up in discussions, but it almost never matters in practice, and it is even not universally considered a bad thing. I actually like to see in the signature if a function I'm calling into can suspend for an arbitrary amount of time.
Assuming they also included Leetcode, I think they're venting about the general "tech culture" which surrounds most programming jobs now
Yes, this is for whatever reason a favorite disaster scenario so it has been tested many times. A training pilot on the ground walks the person through what to do and they can usually get the plane down with autopilot.

This assumes no major failures and no difficult conditions, with operational nav aids like ILS.
Thank you, I’ll check these out.

I resisted Frappe Cloud because I want to own my ERP code and run it on my own server.

I recently started using Beancount, and liked the concept of plain text accounting so much, I want an ERP with the same spirit.
yeah, imagine if a new version of vim changed keybindings.
I remember seeing a few benchmarks where v8 and go were competitive or sometimes even slightly more performant.

So not even sure that GC has always a perf cost is always true.

Not saying it doesn't in some cases, just so that we are clear but the truth seems to be more nuanced.
> I love beancount

I've never used PTA software before, but I just tried beancount and I'm really liking it so far. Just set up my checking and savings accounts. The Vim syntax highlighting sealed the deal.

Looking forward to getting back on top of my finances…
I'd just like to say that I've spent a good portion of day telling everyone who I think will be interested about this.

Thanks for sharing!
They should sue the sea, I guess.
I was pretty impressed by the power and accuracy of the Google Translate offline models (which predate some of the amazing new LLMs), also in a seemingly amazingly small space—tens of megabytes per language, if I remember correctly?
> I'd much rather see a calculation of how many years of life are lost, an actually meaningful metric.

It's only a google search away! Looks like the rich live about 10 years longer than the poor in the US. See https://www.ncbi.nlm.nih.gov/pmc/articles/PMC4866586/
20 years on a mac and I'm still learning stuff, thank you!
Common dreams is known for click bait stuff like this.
If Apple would supply the parts.. This would also not be a problem anymore.

Besides, I'd rather that my stolen phone is useful to someone (even if not me) then thrown away by me after a year. As long as the software made sure nothing of my data is recoverable.

No, I'm sorry but this tactic is nothing but anti-consumer and anti-green.
There are a few old-adage counterpoints here, such as: don't make your passion/hobby your job, have hobbies outside of your work, etc. But you also touch on something that has surfaced as the money in tech has grown and become much more loud in the last few decades.

> Bootcamps have just become farms for people who need a job, but not those who really want this job.

This isn't exclusive to bootcamps - they just happen to be the most expedient way to act on particular desire. The real problem is how LOUD money has become in 'tech' in the last several decades. When I started undergrad ~10 years ago, at a small school not known for anything Math or CS, there were still a lot of students who entered the CS program because they heard, from their family the internet or the world at large, that it was "a good job". (This also stems from college being seen as 'job prospect' improvement as opposed to something for learning, but that discussion lies elsewhere.)

I got lucky that I liked it. Most of them would drop out of the program / transfer to a different area of focus within a year or so. There were probably somewhere around 50-60 people in my low level CS courses. My graduating CS cohort was 9.

Despite liking it, I still find little desire to tinker on things outside of work. A large part of it is that it _is_ my job. I don't want to work, then go home and 'work' for 'fun'.

The other part of it is, as mentioned by others here, the parts of software a lot of us enjoy the most aren't usually what we get to focus on, in one way or another.

> I want to work with more people who LOVE software and find the development of machines and the code that runs on them as fascinating as I do. Unfortunately, its less and less these days.

I get the impression most of this is going to be exclusive to small projects, teams, and in particular startups. Bigger operations are going to prefer prioritizing the more 'stable' or boring sides of software.
i think seo people are doing some negative sum stuff that is bad for society
Swift's refcounting is atomic (as is objc's). As long as you're not under contention most benchmarks I've seen show negligible overhead (from the addition of atomicity, the refcount overhead is still there) for uncontended access. But IME if you do have many threads walking the same data structure you end up spending stupid amounts of time fighting the refcounting. This applies even if the data structure is immutable and has guaranteed lifetime as swift's type system doesn't seem to allow that to be expressed, and as a result it seems to do a lot of ref churn we'd consider unnecessary.
You’re missing some of the nuance of the bug.

CORS only stops you from fetching and reading resources, not from evaluating JavaScript with <script src="…">. (Fun related topic: JSONP.) This vulnerability depended upon the fact that a JSON array literal is a valid JavaScript program that just does nothing (unlike a non-empty object literal, since its opening { will be treated as a block, and so `{"key":` triggers a syntax error). Thus, you could use <script src="/path/to/json/array"></script> and it’d run just fine, doing nothing—except that back then you could intercept array and object creation. That was the crux of the vulnerability, and that was fixed in ECMAScript 5.

As for sane default browser policy: the only policy that has changed here is SameSite=None → SameSite=Lax on cookies, and that has actually still only shipped in Chromium-family browsers.
i think its a bit strange to blame medical costs, such as expensive treatment X for serious disease/injury that didnt exist 30 years ago, as the cause of someones death, who would have been dead without that treatment.

the money involved in healthcare does bring up some interesting thoughts.

i remember hearing that the "war on poverty" didnt impact poverty rates because govt guidlines dont factor in gov't social services such as $ amount of medicaid recieved, food stamps, etc.

so really the cause of death should include poverty + depending on X govt services, not either or
How is passing in a context “coloring”? This is GC for goroutines — specifically long running ones.
Was probably due to FFI for Go I'd assume.

Do you have a reference somewhere I can read up?
This is an amazing article; I expect I'll get a lot out of it next time I have to debug a Cable modem problem.

> Some cable modems (often based on the Broadcom chipset) expose a 'Spectrum Analyzer' interface on port 8080.

I had no idea this was a thing, but it turns out to exist on the SB6183 (http://192.168.100.1:8080/), though doesn't support Firefox for some reason.
This works until you want to change your email domain (or provider in some cases)
Something I've done a couple times is trace the execution of a system call by reading the code. LXR is really helpful.
Yet another chrome wrapper, but with VC funding.
3rd iteration of that joke on this thread.
you will not get the richness of detail that 23andme provides though, since the results are mostly based off training data from other submissions to 23andme. Which is why it gets better over time; I was shown to be 20% Chinese, but now 4 years later my profile there reads that I'm completely Korean
I don't believe there should be a "point" where you can say that. Medically-assisted suicide should be available for everyone. Of course with a prolonged evaluation period.
The alternative is I2P. It's slow but anonymous.
why not just stop drinking caffeine, or drink less?
Even if it was a 100% Apple language, that would still be quite relevant. Apple's devices are pretty pervasive, especially among the well off.
> In other words, buybacks are a way of paying way less tax.

Not way less, just choosing _when_ to pay a tax (say, during retirement years instead of working years of one's life).

I don't see anything wrong with doing this.
Or a solid case for alternatives to standard username / password login concepts.
qb-escape – QuickBooks to GnuCash migration scripts
In my experience they don't get run over, but they can get outnumbered. If you're in a workplace with more than 10% of people that are dishonest or malicious you should look for an exit.

Those companies create worse software and not more reliably or quickly. You can't micromanage into good software.
Cause distraction.
So, I have this issue as well, but I found a way around it.

Add the google account to an old android phone you don't use (maybe even an emulated android would work) and it skips all the verification stuff simply because it's on a phone. That way you can keep it logged in and change things even if you can't log in via a browser.
Wholeheartedly agree. I'm a self taught programmer who programs to get things done rather than just doing programming for fun (I started in ML/data science field). That way, my code often resembles the caricature of these hacky codebases alluded above. And I'm well aware of it.

I often have arguments about utility of Python with my more technically solid engineer friends who keep telling me "Python doesn't scale" etc. And I often come back to the same point you highlighted: is the particular hell worth the result? For 85-90% of the cases the answer is resounding yes.

For nimble teams, startup projects, internal tools : most of the code is often thrown away eventually. Python's beauty is that the language quickly gets out of the way. Everyone then is forced to focus on complexity of the business domain, "does the code solve the business problem". The architecture/scale/speed problems will eventually arrive with Python. But most purist engineers overestimate how soon it will come. At most of the failed startup attempts I was part of, the PMF problem was more pressing to solve than software constraints.

Early days of YouTube, Dropbox, Instagram (and maybe OpenAI too) are big testament to this. I've made my peace these days by not fighting to prove Python is the best language etc. If someone tells me "Rust beats Python" kind of argument: I say I agree, wish them luck and focus on shipping things.

tl:dr; Python is still the best choice to "quickly deliver value and test your business hypothesis".
I think, as you move on to higher and higher paying positions, you slowly start being surrounded by people that optimize for money, instead of skill.
It's nice and frustrating to see a wider audience struggle with this. It's not really a new one, though there are some hucksters out there that have made it their soapbox. This has been sort of a settled conclusion for a number of years among who I'd consider to be mature, reasonable researchers in the community.

AI is good at filtering large amounts of data for final human review. There are some information sieves that work well with large generative models. It will likely not fully surpass humans until some set of benchmarks consistently beats human performance by some multiple factor much greater than 100%. In that case, we'll have some ethical questions about what to do about it and what is the most appropriate way to transition if any, but having a human making the final decision for now seems the most appropriate route until we have more information about what things look like in the future.

That's my best understanding, and both a mix of my opinion(s) and what I've heard from others. Any much beyond it I think is a very silly argument.
Honestly a heart attack is how I hope I go, over in minutes!
Why would coffee be a net positive, even in general without any genetic mutations?
Please tell me you let chrome save and sync your passwords lol. Always a delight for pentesters and real attackers a like when people do that.
Natália Coelho's post on Guzeys criticism of Matt Walkers book is scuffed with inaccurate methodologies, and redundant circular arguments, counter to popular understanding of sleep mechanisms

(I'm kidding, but I couldn't resist pointing out how meta the dialogue around sleep has gotten)
Oh, I want to clarify as well, that in talking about equivariances, I'm talking about the molecule generation side of things. So my main comment wasn't originally intending to get into textual language model stuff.

Molecular dynamics is an entirely different beast that my best understanding is that it's quite difficult for a number of reasons.
The lack of symmetry bugs me - if a couple swaps wives, why isn't it ever called "husband swapping", and wouldn't the (technically, and politically) correct term be "partner swapping"?

Or maybe it can all be subsumed under "swinging" or whatever the modern term is?
Others have talked about your legal (just no) and not-so-legal (a quiet side agreement) avenues.

Another approach is to try to push the issue harder with the controlling shareholders and Board.

Perhaps get together with your peers who also have non-transferrable stock, and even with the founders if they are in the same boat. If there is enough demand for sale, especially from current staff who are critical to the business, then you have a lot more bargaining power with the Board/lead investors.

Meanwhile if you can really get enough people (or $) interested in buying shares then the amounts at stake will be increasingly be material enough for the Board to take notice.

Smart investors would allow the shares to be traded (as secondaries), as keeping staff and former staff happy is smart long term. Not allowing trading devalues also the value of new options being issued to current staff, and I've seen later stage smarter firms blow up these rules and allow for share sales.
Most of the times, cgpt’s browser “fails” to click on things…
Do you think you could ever generate types for go? The protobuf implementation of oneof in go is pretty rough to look at, and not fun to type over and over.
Oh this is talking about straight up prices for the trains. Unless you live near the hubs and need to go to another public transport hub you can easily expect your journey to take 2-3 times the time it'd take if you took a car.
Skeptical it can glean all of that without EEG, let alone without heart rate.
Not really sure what you're getting at. The devices we're discussing are cheap, not free.
Pressing Esc did stop the animation, but I'm not sure you could step over it.
Open question: in what fields are you working where you really need to work with actual sockets? Most of the network programming I do fall into one of two categories:

1. A library exists to abstract over the bytes-into-sockets layer, meaning I don't need to deal with it; or

2. A library probably exists to abstract over the bytes-into-sockets layer, but I've chosen to ignore it either because I'm truly ignorant of it, or for intellectual stimulation.

(Note that in category 2 I count things like "not using protobuf/thrift/etc. for IPC.)

When are these things not true? Genuinely curious! I'm guessing interfacing with existing obscure third parties, or using obscure language environments, but what are examples of that? And what other usages are there?
It's nice that generated code works in browser but I was curious whether it's possible to actually generate code from .t syntax all in browser.

By the looks of it typical is only a CLI tool, so I guess not for now. Maybe unless it is ported to WASM...
You could have said the same things about image generation 18 months ago.
I'm really, genuinely happy for you that the thing you're passionate about is something you're good at and is extremely lucrative, but if I tried to make a living doing what I'm passionate about I'd live in a cardboard box. The reality is that software eating the world (and admittedly a number of other things, but this is a big one) have made it much, much harder to make a living doing just about anything else. I got a job in software development because I was good enough at it and I needed to pay the loans from pursuing my passion. I continue doing software development because it's a way to eventually maybe escape capitalism without swallowing a bullet.
There's probably lots of data everywhere but here is "Poverty rates in OECD countries as of 2021" to compare where the US sits against other countries:

https://www.statista.com/statistics/233910/poverty-rates-in-...

They're probably using the ~6.85$ a day ("upper middle income poverty line")
https://ourworldindata.org/poverty
it'd be interesting to make a game where the units aren't hardcoded either - and to play against someone, you'd have to "figure out" what their units did and what weakness it would have (i imagine it would work by a point system, where for example, if you put more into health, their attack would be weaker etc).
phind is really good for certain kinds of programming and IT tasks, i've been recommending it to friends and colleagues for weeks now.
Cut the caffeine, increase the morning exercise. These were by far the biggest improvements for me.