Hacker News new | past | comments | ask | show | jobs | submit | d1l's comments login

24 zx6r to replace my clapped r6, which had nearly 50k miles. Love it even though the rev limit kicks in at 14k (as opposed to the 17k on the r6). Now that it’s cold I’ll be sending it off for a flash to get that raised to 14.5… Love the ninja, though. That bike only wants to go fast.

Site calculates a 40deg forward lean but the best is full tuck behind the windscreen with the throttle pinned.


If you maintain a library you’ll hear about this kind of shit early and often.


The last thing anyone needs is “visual” “designers” shitting up our useful applications.

Stick to your todo list apps and stay in your lane.


This is such an aggressive way of saying something unhelpful. Visual/information/interaction. design -can- be an important part of an app team. I also think calibre is clunky and many of their interactions inelegant. That it’s also ugly is not irrelevant - reading is or can be an aesthetic experience too. I’m grateful it exists but like Anki I really wish someone with real design skills could help them polish the rough edges - that would make it a pleasure to use rather than just ok.


Some designers are definitely terrible (e.g. whoever made the mind numbing decision to use hamburger menus in Gnome), but plenty are good at their jobs. Go and watch some Tantacruul videos on YouTube.


This is just yet another attempt to piggyback off the HN crowd's enthusiasm for Sqlite in order to advertise fly.io.


I mean not fly.io, the author Kent C Dodds makes his living from selling web courses.


Man does not live by bread alone. If you want to make technology and the standard of living a god, that might be rational, just as communism may be an earlier rational attempt in the same vein. But I believe these ideas are naive. The central idea seems to be “eliminate enough of man’s animal suffering and cater to his animal wants and you’ll have paradise” but I think these schemes undervalue the human need for freedom, love, self discovery, and meaning.


In that time there is relatively little figurative art of humans. Rarely seen in cave painting, etc. The nearest would be the Venus figurines but they don't typically show facial features or internal anatomical details. It's a major major find bro.


I haven't seen much art from that era either and was pretty surprised to see the statue. However looking into it, I'm even more surprised to learn of the Venus of Brassempouy.

I've heard that much of the ruins from Ancient Greeze were likely brightly colored and painted. I can't help but wonder if the Venus I mentioned had been painted as well. It's possible that they did have detailed faces, and that they simply weren't sculpted.

I'm the furthest thing from an expert of course.


I suspect it’s more a problem about longevity of the artifacts, rather than lack of talent or knowing one can pick up some mud and form a shape.

They had very similar general intelligence and talents as us, at that time, and tens of thousand of years before. Today, it’s not terribly hard to find artistic kids who can mold extremely good faces, ponies, or whatever else they choose, from a lump of play dough. I assume artistic people existed then too, with comparable talent and frequency, unless there was some catastrophic non-artist pruning that happened very very recently.


A statistical review would show that you are almost certainly quite incorrect.

Also, the "they" you refer to is "us".


Could you expand on that?

If they’re “us”, then that statistical review should show similar distributions to what we have now, especially in children. Can we see the artistic child’s work? It’s probably made of mud, so probably not. We only see accidents of preservation, due to the tools and final materials.


I don't understand why it is so radical though. Even when I was a bored kid I could pick up a stick and whittle out a face not to far from what was in the article with a decently sharp knife and some time. Doesn't seem like a huge jump to do it in stone if the stone is easy enough to shape with a harder stone/mineral...


All greenlet does is allow the Python frames to managed separately from the C call stack - it is very similar to what Pypy is also doing. I don't think your characterization is at all accurate.


Sorry I wasn't clear -- my point was that a typical python programmer won't be able to troubleshoot these bits -- it'd be way outside their skill set.

Before anyone jumps in to say nobody ever has/will ever have to troubleshoot this because it's so stable and used everywhere and so forth, please have a look at the comments at the top of that file. This code had to be patched eg. due to a compiler update.

Remember, this is open source and this code is offered without any guarantees. And non-existing guarantees of greenlet/gevent is quite different from the non-existing guarantees of CPython (no idea about PyPy).

Implementing cooperative multitasking at this level is way off the beaten path and should only be attempted by those who know what they are doing.

Today, I'm sure this code works perfectly on linux 6.4.7 when compiled by gcc 12.3.1 against python 3.10 on amd64 architecture in release mode. But can you guarantee it will it work on linux 7.8.17 when compiled by gcc 15.2 against python 3.21 on AARCH64 10.4 architecture? No you can't. If you are lucky, it'll just die with a general protection fault or something. But it can also break in subtle ways that only a seasoned systems programmer can realize, let alone fix.

So if you are a professional, you care about maintainability, you care about forward compatibility, you are starting a greenfield project, you are sure you need cooperative multitasking and you ask nicely my opinion about which async framework you should choose, I would strongly advise you to steer clear of gevent/greenlet based libraries.

Or, you know, just hack away :)


Our well-thumbed and torn cars book was a favorite of my brother's and mine. Half the pickle truck is missing and my kids speculate what other vehicles might have been on the missing page. There's no lesson here other than, I think, that when someone creates something good, honest, and with love, then that thing is worthwhile and praiseworthy. The love shows in every detail of his books.


Couldn’t agree more - my kids have been reading the two “big ones” - Cars and Trucks and strings that go, and “What do People Do All Day?” almost every night for a year now. There’s always a delightful new discovery and it’s an endless source of “Why?” questions with interesting answers!


This is the so self-serving and self-congratulatory! He had the nerve to cry on her doorstep, which says he didn't want to apologize, but to be forgiven and to make a show of it.

Amending past wrongs is about showing up without any regard for your own feeling and the intention to do whatever is in your power to set the wrong aright. You admit the wrong and then you listen.

I get it that to the author this is some cute meta-story about "we were both wrong!" But truly acknowledging one's fault is antithetical to this kind of fawning over oneself and infantile moralizing.


That’s harsh. Showing up is demonstrably an action in the direction of making things right , apologising is not out of a pure disconnected entity, but out of a being with feelings, driven by them to do right. Perhaps if the story was different, he would have gotten the proper moralising tune, but that was his experience and that’s the tune he found appropriate. I don’t agree with his findings but that does not mean I question his intentions.


That's funny, I read it more as a story about forgiveness and how often we carry around these life burdens (guilt, anger, whatever) solely on an emotionally-charged misunderstanding of what we think to be the truth. It got me thinking about what stories I keep telling myself that I may be clinging to that are potentially incomplete or incorrect.


You've conveniently described python behavior but lots of C code relies on the gil implicitly and will need to add locking to be correct in a nogil world.

I'm not saying for sure this is bad! I do think it is dishonest though about the potential impact. Lots of critical libraries are written in C.


This is why the proposal is to, by default, reenable the GIL at runtime (and print a warning to stderr) whenever a C extension is loaded, unless that extension explicitly advertises that it does not rely on the GIL.


Dishonest? I didn't hide that fact: "Removing the GIL will require a new ABI, so existing C-API extensions will minimally need to be rebuilt and may also require other changes. Updating C-API extensions is where the majority of work will be if the PEP is accepted."


Yeah but everyone knows that is obviously the biggest issue. Nobody was really concerned about the Python code which is the part that you said will go swimmingly—that's table stakes for a change at all. We already assumed the pure Python code would upgrade easily; a change would have no chance whatsoever of being accepted otherwise. Everyone is worried exclusively about the C extensions, and always has been. This seems to have been presented as a new approach to GIL removal that fixes the problem with C extension breakage but it's just the exact same old approach we've always been considering that breaks the C extensions. No-GIL ain't done until all the C extensions run, especially NumPy.


> Nobody was really concerned about the Python code

This was the top comment when I added my original comment:

"Fundamentally every single piece of python code ever written will have to stop and now worry about potential race conditions."

https://news.ycombinator.com/item?id=36644114

Most of the other comments here at the time were similarly from people who clearly hadn't read the PEP saying it would break all existing Python code.

So I did my best to represent the backwards compatibility section of the PEP. I told folks to go read it and linked to it. I cited the portion relevant to Python code. There were too many bullet points for the C-API, so I summarized it with the disclaimer "Updating C-API extensions is where the majority of work will be if the PEP is accepted."

I also read the PEP discussion thread where there was disagreement from Python maintainers on how much work would be required of C extension authors, but most of the folks stating it would be a lot of work hadn't seemed to actually have tried to port anything to the new API. Meanwhile Sam had asserted that:

> Most C API extensions don’t require any changes, and for those that do require changes, the changes are small. For example, for “nogil” Python I’m providing binary wheels for ~35 extensions that are slow or difficult to build from source and only about seven projects required code changes (PyTorch, pybind11, Cython, numpy, scikit-learn, viztracer, pyo3). For four of those projects, the code changes have already been contributed and adopted upstream. For comparison, many of those same projects also frequently require changes to support minor releases of CPython.

I don't think I've misrepresented anything.

> No-GIL ain't done until all the C extensions run, especially NumPy.

Sam already got NumPy working without the gil:

https://youtu.be/9OOJcTp8dqE?t=1958


I think the word "minimally" makes it sound like the changes to existing libraries are "to an extremely small extent; negligibly." "At a minimum" would fit better, because the minimum of a set of things can still be very large whereas minimally implies the quantity is very small.


But it was downplayed in the comment when it was always the #1 reason for keeping the GIL. Python level changes were never a serious part of the argument.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: