We don't even need a kernel anymore. An agent can write the relevant parts of the OS on the fly, as we need them.
1,537 karma · joined June 8, 2015
1. Reflectors are the best for baseline visibility, they cost nothing and are reliable.
2. The tail light is the important one.
a) Try to find ones with a pulsating mode, blinding other road users by shining bright rapidly blinking lights into their eyes is not good, actually.
b) If you've got the money, consider a radar instead.
3. For the front, decide if you *need* illumination strong enough for you to see where you're going in darkness, or if you can get away with just being seen by others.
a) For the former, make sure you get a front light that has a beam cutoff, preferably a lens-based solution. Then of course, install the light with a proper downwards angle, otherwise there's no point to the cutoff.
4. Side visibility is important, this is usually accomplished by some see-through parts at the business end of the light.
5. DO NOT use blinking modes at night. Blinking is for daytime, use only constant or at most, pulsating modes at night.
6. BTW, the 2nd most important piece of equipment after your tail light is a mirror (>=2inch diameter).
• If biking casually or without a need for strong front light, honestly just get the cheapest lights you can get + some reflectors. Having any light at all gets you 99% there.
• Magicshine lights in general, I myself have the EVO 1300 for front and the SeeMee 300 for back. Proper lensed beam cutoff for the front, pulsing modes for the back, and good side visibility for both.
• Bontrager Flare RT for the back — small but powerful thanks to its focused beam. They also seem to have a front positional version but I haven't tried it.
It's because 99% of bike lights are basically just flashlights, spraying light everywhere. The solution is the same as for cars — lights with horizontal cut-offs.
The problem, really, is assuming that the alternative to a slop website is a non-slop website. But the alternative is often no website at all.
Having said that,
> And my profile has an “active student” badge.
Ahh, and the icon is vertically misaligned with the text... what is it with AI and zero ability to keep things aligned and consistent?
Just how Go adding generics to the language didn't magically fix the billions lines of non-generic Go code, adding virtual threads to Java didn't update its entire ecosystem to take advantage of them.
Meanwhile, the entire Go ecosystem from the beginning took advantage of goroutines, so all code you'll ever interact with will have excellent support for them.
As opposed to writing a prompt for 30s, then doing something else for 15m while the AI works on it? :)
> The real challenge is forming the new ideas in the first place and most of those new ideas coming either from using the code as a product [...]
Exactly.
AI is absolutely excellent at rapid prototyping. Prompt -> result -> use the product -> prompt. Repeat until the right design emerges. Once that happens, the code can be cleaned up, or even rewritten from the grounds up, taking into account what was learned.
That any of this would be needed is a problem on the AI side, not the user side. It can't be expected that everyone puts in hours of upfront work, trying out models and different ways of working just to see if AI is there yet for them, every time a new SOTA model comes out. Time is limited.
Also, the more thought, time, and effort needs to be put into prompts, the less useful AI is.
> I took your prompt and gave it to a junior dev, would they know what to do?
While overall I'm getting decent enough results, the AI often makes mistakes that no human would make, like not styling or aligning a new button on a webpage the same as the buttons right next to it. In general, it has major trouble with having a coherent vision of the entire project.
It's also obedient to a fault, never pushes back on anything I suggest. I'm pretty sure if I asked for a low user value feature that nevertheless would have to increase backend complexity 10x, it would go ahead and just code it, no questions asked.
> I don't think AI is the second coming of Christ or that we're anywhere near AGI, but I do believe it's an extremely useful tool that people should be using.
Ah, same. Just remember, we're very early into LLMs, they're still very much a sharp tool for experts, not really safe or convenient to use for everyone (yet?).
I would very much like to be reminded of and updated on the current conditions of those workers.
Much in the same way I'd like to be up to date on whether Mr. Musk has ceased to be a nazi. Seems not.
BTW, Anybody know if things have improved any on the Chinese assembly workers front?
So literally just a broken limb. Non-life threatening, can wait. Sorry, triage is a bitch. Some patients will literally die within minutes/hours if not actively treated. Go figure.
> In the US, I was rushed into the ER in an ambulance
The second they dispatch an ambulance, you owe them how much exactly these days? $5000?
This alone is enough to tell you have no idea what you're talking about, and it's not even about the ambiguous usage of the word "faster".
There is no way for performance claims that are
a) this accurate,
b) this small,
to possibly be real.
You certainly just cherry-picked favorable benchmarks.
Ah, here it is: "Over sixteen benchmarks Goose runs at about...". First, let's make this statement actually correct: "Over sixteen microbenchmarks Goose runs at about...".
That's not the same statement as "1.16x faster than C++ and 1.12x than safe Rust". Not by a mile.
You need a test suite comprised of a wide variety of real world programs, not 16 microbenchmarks, possibly specifically chosen to play to the strengths of your language.
Doesn't bother to disclose it of course, because what, you don't check everyone's profile in every discussion to make sure they're not biased? What, you don't just know who every user on this site works for? You dummy you :)
Production incidents are comparatively trivial, irrelevant issues.
Ah, literally the worst thing you can ever do, the in-between. Either go or stop, never do the indecisive middle route. If in doubt, default to stopping, though in this case of course the default is to go-around.
Although... it's probably going to end up the case, as is usual, that were they truly committed to landing and started braking hard right away, they would have ended up fine enough. Indecisiveness kills.
A big part of the monitoring pilot's job is noticing when things have gotten too far and taking over controls. This does very much include scenarios when the pilot flying has fallen to tunnel vision, subtle incapacitation, and the continuation/sunk cost fallacy.
Now, really? As far as backwards logic goes, this is up there. Better to break the law and endanger others because what, some can't drive for shit?
A better example would be mixed boys/girls sports classes in school, where the boys deliberately hold back as to not injure/scare the girls.
It's a pretty obvious and human thing not to go out and completely destroy a much weaker opponent. We're social animals after all.
There also may be an element of energy conservation, there's objectively no need to put in any more effort than necessary. Inefficient.
"Maybe you don't understand people's needs and motivations as much as you think you do."
It's the opposite. You're confusing "needs" with "wants" and extrapolating the needs of the very, very few people who genuinely need a truck onto the entire population.
The vast majority of people use their cars to transport only themselves to work each day, then maybe pick/drop off one more person, then maybe go buy groceries.
I don't think you quite understand just how ridiculously niche valid use cases for trucks are. It's literally just towing, or some very specific off-road hauling. Everything else is going to be handled way better by something else, starting with a regular car, ending with a van.
Hell, for most people even a car is way overkill, a bike works perfectly fine to go to work each day, I assure you. So does public transport. You don't need 2 tons of steel just to to move your 100 kg body around.
To your analogy, I can use my dinky little chromebook 99% of the time and only boot up my PC when I actually need the power.
Watch this:
- My trucks require roads and do more damage to roads than trains do to rail tracks? No problem, roads are paid for by the taxpayer, while the rail companies have to pay to build and maintain their tracks.
- My trucks produce harmful emissions and particulates that trains don't? No problem, I don't pay for any of that.
- My trucks kill people in accidents? Again, no problem, not paying for any of that.
Yay, we've successfully optimized out any inefficiencies of trucks by externalizing literally all that's possible to externalize. Isn't the free market great?
I would be able to draw an accurate bicycle, but I'm an outlier on that. Most people could not draw one [1].
[1]: https://www.booooooom.com/2016/05/09/bicycles-built-based-on...
"Cyclist" and "someone on an illegal e-bike" are not one and the same thing.
> And you can see here "normal" bikes clocked at 36 Km:
No, those people freewheeling on a regular city bike on relatively flat ground are not doing 36 km/h. That's around 20 km/h by my somewhat well tuned eyeballs. Have you never been on a bike and measured your speed?
You're not going to be seeing cyclists going 36 km/h beyond significant downhills or sporty people on drop bar bikes putting in significant effort.