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

>Rear-ending someone going slower than you is not their fault.

who gives a shit who is at fault when they're in an accident?

the goal is to avoid the event all together, not to have a scapegoat.

The type of people who see a "lane ends ahead" and immediately merge, blocking up traffic and wasting a half mile of empty lane. "I'm in my assigned place and I did what I was supposed to!!"

The thing that blocks up traffic at a merge is when people can't get over smoothly.

If everyone gets over at the first opportunity, then things go fine. The empty lane isn't wasted, it absorbs brief bursts in traffic that need more time to get over. But even if it was wasted, that wouldn't be a big deal. A 5-mile long section with fewer lanes and a 5.5-mile long section with fewer lanes will have almost the same throughput.

Everyone staying split across two lanes until the end and aligning themselves to do a clean zipper merge also goes fine.

What makes everything go wrong is when people drive down the nice empty lane that's ending and intend to do a normal merge at the end, but they don't start it early enough. Then everything slows down as they squeeze over.

In my experience what causes the slowdown are the people who merged too early who then resentfully close the gap in front of them when people try to merge later than them, simultaneously increasing the likelihood that they’ll rear end the car in front of them and making it harder for the people trying to merge properly to do so.

'...when people try to merge later than them,'

You mean the people who must get past every single car and merge at the last possible second?

Doesn't that just move the gap slightly? If anything, a tight squeeze should mean the gap behind them is even bigger than the gap that existed before.

ahh that takes me back. I used to be addicted to this back in the SubSpace VirginNet days.

trench wars sniping was the best.

Same. I can’t believe this is still a thing.

there is a lot of spontaneity in the act of sex that you're taking for granted; it's not that easy to throw that away and get the same thing out of the event.

rigor and standards are often the enemies of passion, so it's a hard sell. Your base logic is right, prevention is the best cure, but humans just don't work that way.

you can sorta-kinda do that with anything with a high fat content.

the fat interacts with the gum base and emulsifiers. the fat also coats the components in a way that reduces likelihood of re-amalgamation.

Right, any oil and gum.

>If one volunteers to participate in a study of a drug suspected to reduce drinking, that itself is a contradiction of the exclusion criteria.

no, it isn't. many trials offer financial compensation -- they may not be seeking treatment but rather just a payout.

stitch the images together (sift,orb) and apply a perspective transform.

if the images are uniform enough in style you can then probably crop them all at once with mask coordinates.

opencv/imagemagick will handle all of it.

if the images aren't uniform enough to crop them all at once, consider the use of a 'lazy susan' style vertical rotisserie, take all the photos from the same plane, easy post-processing.

>Git is not just a fad; it's a literal underpinning of most serious software development these days, especially if you need to work with others.

yeah, but all of the VCSs before git could've claimed the same thing.

if that's not a fad, what is?

i'm glad git is the soup du jourre today , it's a lot nicer to use than it's ancestors -- but it's not like there isn't room for improvement, either.

that's how git came about, I don't feel like we're at the end-all-be-all VCS yet, especially when there is money to be made by doing things better.

> especially when there is money to be made by doing things better.

Is there though? Why would I pay for a VCS when there already is Git, Mercurial and other free and open source solutions?

Git may not be the most intuitive but it's a solid product and most people work well with it, even those who every now and then delete and re-clone a repo because they don't know another way to get out of a pickle.

Accept my upvote. The silent cowards who are downvoting you hate that what you're saying is true - or at least are tacitly admitting that they can't actually form a counter-argument.

Git deserves credit for popularizing distributed VCS - which is HUGE - but it was not the first or the best DVCS. Its CLI is full of footguns and it's too eager to irreparably erase history.

who cares?

git is a tool, not a discipline. It's made to facilitate work, not to create a whole knowledge domain unto itself.

I wouldn't fault a seasoned and well trained mechanic for not knowing the specifics of a specialty tool necessitating the need to find the manual; similarly although git is the current VCS-ish thing of choice right now, it doesn't represent all of computer science.

VCS is something that is interacted with multiple times a day in any codebase. It is a basic tool, not too far apart from being able to traverse a file system. The next step after viewing files, is being able to commit to and view the history of those files.

I dont know if that answers "who cares", but a mechanic that does not know how to do something they need to do multiple times every day - there is a skill gap. While CS is about theory, I would expect a CS grad to have used all of the basic programming tools and more.

Any code base?? I question your depth of exposure.

Been programming since 98, professionally since 08.

If a codebase has no VCS.. that seems almost ideological. I've done a git init on a linux file system to understand patch changes.

With that aside, what does disaster recovery look like without VCS? Remote backups ate an obtuse form of VCS.

If your laptop explodes, are you losing months of work? I mentor junior devs to push daily, if their laptop blows up I want them set up again in 30 minutes with at most one days worth of work lost (because they push their branches remotely, if only for the redundancy. Doing so daily makes it easy to recreate what was lost, compared to a week or two of effort).

Without VCS, integration is s larger challenge. It can be done, but continuously and also efficiently?

Seemingly we are talking about non collaborative code bases, a vanishingly small subset of projects. Most software is developed by teams.

Last, it is so damn easy to run 'git init'. My last job - the team used git locally and then did the stuff in TFS when they finally had to. The point is how easy and useful it was. The other guy that did his own thing, did not use VCS, his stuff was scary. His code was disaster if it stopped building, of if we lost his laptop.

Which is to say, VCS is an underpinning for CI & CD, DR, and is stupid easy to get the init setup done. Just about any codebase - yeah. Even if that means doing git locally and then throwing it away.

It is different to choose to not use all the tools compared to not being able to use them, and yet another to be unwilling to learn them either due to prejudice.

I agree with you. I misread “VCS” for “git” and that’s where my (mistaken) disagreement came from.

Second response after having thought about your question a bit longer, re: "any code base"

First, VCS is a generic term. Saving files to a backup is a VCS, zipping and sending files via email is a VCS.

What kinds of system use VCS as their underpinnings? Build systems, disaster recovery systems, deployment systems, more... Without VCS, you can't have those systems, and which code bases require none of those systems?

Perhaps we are talking mostly demo projects, small ad-hoc scripts. Would you posit other examples perhaps? My perspective is that it is so trivially damn easy to get a VCS set up locally, even a distributed one, that while - yes - you can live without it - in what cases should you really be living without it? Particularly in light of all the downstream dependencies of a VCS.

Maybe we disagree on the ROI of VCS? I can understand someone not building a CI/CD pipeline because it is kinda costly and maybe won't be used enough to justify it. With Git (VCS), there was a time period where I was new to it and was corrupting files left and right. Getting past that, the cost to set up & use is absurdly tiny, my daily workflow has had no issues for years now. Perhaps there is a difference in perspective there? That you view the ongoing cost to be really large? So much so, that a cat walking across your keyboard is so rare and the daily pain so large, that you have a different perspective on the ROI?

> git is a tool, not a discipline.

> the current VCS-ish thing of choice

It's not like they're using mercurial instead. There's a lot of concepts here they should be familiar with.

> the specifics of a specialty tool

Are you calling VCS specialty in the context of a CS degree? I wouldn't.

It’s a fair point. At the same time, I think it’s pretty important to cover VCS at some point in college. My CS degree included a couple classes with projects where we did project management, code review, VCS, working with stakeholders, design, etc. —- most of that is just part of life in programming. It’s good to at least touch on it in college.

What about containers. These are now pretty ubiquitous too. Should they also be taught containers? Package management? Document management systems?

I feel like there's a line where we expect some on the job ramp up. Version control was not ubiquitous 20 years ago even if it technically existed in some early form. We honestly weren't really using SVN/CVS much back then and git wasn't invented 20 years ago. Containerization is another example where it was not ubiquitous even 10 years ago.

What if some new technology becomes fairly ubiquitous across the industry? There's some line where you need to accept people won't be taught this in a CS degree. There's a reasonable assumption that you'll learn on the job and also continuously throughout your career.

Dating myself here, my SUN Microsystems sponsored university did have all kinds of VCS. Not just the FOTM stuff but also weird academic toys.

>Should they also be taught containers? Yes, because that's how things are done today while 20 years ago they might have all ssh'd into the same server running the development environment and 30 years ago they would have all sat in the same computer lab. And 'taught' in a sense that lists them a few good documentation resources to get them up to speed while using a provided image.

And if they end up with an actual degree they should have covered both hypervisors and containers in an operating systems course.

VCS is an applied project management and communication system in the context of software engineering. Both project management and communication are disciplines.

CS grads don't need to know VCS, but software engineers do.

If a mechanic didn’t know how to use a hammer, I’d fault the mechanic for sure.

I would say that you can put physical computers in that same category. It is unnecessary for a good computer scientist to even touch a computer to acquire the scientific skills required to call yourself a computer scientist.


>scientific return

that comes after 'someone out there' misinterprets our super fast gram probes as weaponry and conquers our world for the sake of their own spacecraft safety.

it's ingenious really, let's antagonize a greater power into wormhole-bridge hopping over here so we can reverse engineer their tech.

/s , hopefully.

If they are so much as inconvenienced by our probes, they are not a greater power but bumbling roboticists like us.

1 gram at an appreciable amount of c is about as much energy as a nuke. Getting hit by a swarm of these while on a Sunday drive would fuck you up, no matter how powerful you are.

The real reason there isn’t a moon colony? Person gets fired and loses their shit, starts tossing 1-2 km sized rocks down the gravity well and … we all die.

Throwing shit in space is a sure fire way to piss off any species.

It would take an insane amount of energy to throw that rock.

To throw a 100 meter rock that would wipe out NY city (and then some), we could do that with modern technology... assuming the rocket never had to slow down.

But you only need one. Maybe two for good measure

Same with a nuke or an engineered pathogen. Throwing rocks from the Moon is less practical though, people would see you setting up the universe's biggest launch pad or railgun for years. It would be the least stealthy, most telegraphed apocalypse possible.

It only takes a 50-meter (radius) rock to destroy a city, a 240-meter rock to destroy an entire region, and a 4 km rock to destroy the planet.

So, I guess it depends on what you want to accomplish, whether they see it coming or not.

"Only". Those are huge! Especially when you consider the city you have to build around them to launch the damn things.

The required delta-v isn't all that much from the moon, and it's more about the mass and speed than the actual shape of the rock.

it's not surprising to me that the bosch mid-drives are failing, they're typically placed at an angle that catches all the run off from every tube at the lowest point on the bike (except on recumbents), and the controller is (usually) integrated.

mid-drives are great, the gear advantage rocks; the bosch units suck but unfortunately they had so much industry sway that a lot of ebike frames are coming out built around the unit -- which is absolutely unlike any other unit out there aside from vague similarities to the bafang units in the same range -- so it forces replacement with the same garbage, or a total re-engineer of the gear train; a big pain.

one thing to be said about the bosch unit : it looks sleek and it integrates well. This is likely a lot of the reason behind the mass adoption, aside from Bosch's presence itself.

I can't see how mid-drives are significantly superior. An electric motor doesn't need any gear advantage and sending more force to the rear wheel seems like it's actually a disadvantage since it put more stress on bicycle components that are often designed for just human levels of force.

As far as I can tell, the mid-drives became dominant just 'cause people wanted to have something the looked more "seamless".

I have rear drive ebike (Avanton Pace 300 v1) and I'm very happy with it (it was also cheap as a show room model). It's responsive and I can pedal up any hill to about a 25% grade. The controller is still mid-frame and the battery inset into the down tube. Thinking about it, my ideal ebike would be a heavy duty frame with all the components just bolting on (plus could use power tool batteries).

In the EU, e-bikes are limited to a maximum power output of 250 watts - anything over that is a motorbike. That's basically the same power output as a decently fit cyclist. A mid-drive allows for sustained high torque even with limited power. Water ingress issues aside, mid-drives also tend to be more durable in off-road applications where the rear wheel is subject to severe shock and vibration.

As I said, my rear drive gives what seems like high torque to me (I think bike's at about the power you mention). I've only taken my bike off-road a bit but it seems like the force on the rear hub and the bottom bracket are things that simply have to be designed for. The bottom bracket experiences both frame flex and the rider pounding the pedals, so it's subject to punishment and the rear hub is cushioned by the tires, spokes and any rear suspension present.

Power is power, there is no combined "power + torque" that measures how much wind you have in the sails. Torque just characterises how much power you can get along different RPMs.

But the EU/UK 250 W cap is so low that it seems unlikely torque characteristics would enter the picture significantly unless you're going very slowly. I think most of the mainstream EU ebike motors are capped this way (vs designed to have a natural peak output of 250W).

Torque (at the wheel) does matter as well as power. With a hub motor, the gear ratio is typically fixed so you're at the mercy of the motor characteristics, but driven through the chain, you can change it. I used to have a low powered hub motor e-bike and it was fast but pretty useless at accelerating from stopped or climbing hills. At these very low speeds, an optional low gear would have put the motor in a higher power point on its speed-torque curve.

Though perhaps you're saying these motors are so over-rated that even close to stall torque, their reduced power output is still 250W? That would be an efficiency loss but not a power loss since they're not allowed to deliver full power at higher speeds.

>> Power is power, there is no combined "power + torque" that measures how much wind you have in the sails. Torque just characterises how much power you can get along different RPMs.

> Torque (at the wheel) does matter as well as power.

If you are getting 250 W of power at the wheel (in other units, 250 Joules per second, or 250 Newton-meters), that's what you are getting, no torque about it.

>> the EU/UK 250 W cap is so low that it seems unlikely torque characteristics would enter the picture significantly unless you're going very slowly

> Though perhaps you're saying these motors are so over-rated that even close to stall torque, their reduced power output is still 250W?

Yes, I was saying something close to that ("very slowly").

IOW the overprovisioning of the motor combined with the power cap makes the motor work much more like a "always 250 W" power source than a "250 W peak output modified by torque" power source.

One nit, it's max /continuous/ output of 250W. Bikes with a temporary boost function to 500W are still legal and they're great to ride.

Electric motors have a wide power band but it isn't infinite[1], gearing does make a difference. If I'm in a higher gear on an incline my motor has significantly less usable torque vs shifting down to a gear that's closer to the power band.

Now if that is worth the complexity/cost is a fair debate but there are mechanical advantages to mid-drive motors.

[1] https://forums.electricbikereview.com/threads/ebike-motor-po...

One might expect some disadvantages to having more spinning mass in the rear wheel.

My local bike shop said they are all in Bosch because they had better reliability and less issues with their support compared to other companies and because of the commitment to long term spare parts availability.

> long term spare parts availability.

The article says that you can’t get spares, any service requires sending to the factory for repair?

I just dropped a bunch of money on a Bosch based bike because I was told they are very reliable.

I'm going to be very annoyed if that turns out to not be the case....

Bosch is in a bunch of high end eMTB setups, including a few of my friends’ rides. We do plenty of wet riding, and the bikes have been hit with the hose for years now to clean them off when we’re done.

If there’s a problem here I think it must be the frame design or the way they’re installed and not an across the board problem with Bosch components.

Your mileage may literally vary but indeed: this no problems with my Bosch either.

The gear advantage of a mid-drive rocks but I was quite surprised that I chewed through a rear cassette in under a year / about 1k miles -- a 250W motor + heavy cargo bike + kid passenger + a large and pretty strong rider exert an awful lot of force. And with the assist, I almost never use the larger cogs, so all the wear gets concentrated. (This compares to many, many thousand miles on my road bike.)

Still love the thing, though.

Maintain your chain! I chewed through a nice cassette on my mtb quickly by not watching my chain and replacing it when worn. A worn chain will dramatically increase cassette wear. I only replaced it yearly and should have probably done twice per year.

Since then, I switched to hot waxing my chains and have now gone a year with the same chain reading as almost new. (Actually use 2 chains but both are barely worn)

There’s a great site called zero friction cycling that details all of this. The key that they opened my eyes to was looking at the total cost of riding including the cassette.

Would an internally geared hub solve for this type of wear?

IGH's are not all that rugged. Most have a published requirement for a minimum ratio between the chainring and cog, that translates into an approximate torque limit. I love my old Sturmey Archer AW hubs, but I'm not sure I'd recommend one for the aforementioned use case.

Shimano E5000 is an IGH rated for e bikes.

Seeing how as I regularly managed to break the drive cross in my 3-speed SA hub just by pushing the thing real hard under pedal power alone - this is 40 years ago - I don't think they're particularly strong. I fixed my bike by myself so all this cost me was a new drive cross but still, it shouldn't break in the first place.

I think material science minute might have advanced over 4 decades.

The cross is made of a fairly hard type of steel. They knew how to make that 40 years ago so I don't think there is any noticeable difference. If anything I suspect the older gear hubs were built stronger than the current ones.

I manage to ruin chain and cassette in under a year on my acoustic bike. The trick is to ride fast in all weather and never clean the chain.

Congratulations, your brief comment has managed to trigger me in 3 different ways.

Why would that surprise you? A semi serious mountain biker will go through a cassette on an analog bike in 2 years. You're driving the thing with a huge motor, cargo and an entire extra human. Your expectations must have been unrealistically high.

The difference between a mid-drive (in which all of the force goes through the rear cassette) and a rear hub drive (in which only the pedal force goes through the rear cassette) is large.

Also, most people online report over 2k miles on a cassette. Pittsburgh's hills and more force are apparently good for some extra wear.

(Also, a 250W motor is fairly small by e-bike standards. They generally start at 250 and go up from there; 750W is not uncommon.)

I have a friend in your same scenario. I’ve never thought to ask how quickly he goes through cassettes on that bike.

I think the follow-on post above about making sure to be better about maintaining the chain is part of it. I'm a little lazy with my road bike chain because I mostly only ride it in good weather, and I carried the same attitude to the e-bike, which gets a lot more stress per mile and I'm more likely to ride in rain.

I'm not hot waxing it, though it's tempting, but I do wipe it down and apply T-9 much more regularly now. We'll see -- I'm 400 miles into the new chain and cassette...

Specialized had problems with their last gen of the Brose motor (2.1?), leading to lots of premature failure. I’d not heard of significant problems with Bosch units, it’s always hard to determine what is truly a design flaw vs a few anecdotes.

> they're typically placed at an angle that catches all the run off

aren't they also directly behind the front wheel?

fenders, fenders, fenders.

something unsexy with a flap / mudguard.

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