asciimike

The OBD adapter should be cheaper nowadays; most folks on the BMW forums will charge ~$100 for coding services, and it's generally "any time you need anything changed, it's free."

If you're in the bay area, there are a few local folks who are happy to do it!

Esys is available fairly easily: https://f87.bimmerpost.com/forums/showpost.php?p=26123409&po... (but as you say, there's some megaupload and a cracker involved).

I've spent quite a bit of time hacking my own F-Series BMW, and I can confirm it's a _huge_ pain in the ass, mostly because there is basically zero documentation on how to do it. IMO BMW also occasionally makes some bizarre engineering decisions, for instance, connect one long wire from an internal switch console to the DME unit (engine controller) rather than connect directly to an adjacent CANBUS that already went there. German engineering ¯\_(ツ)_/¯

I've found the following tools helpful: - newtis.info (has literally all the wiring diagrams as well as a bunch of info on how systems are built and work together, though unfortunately the protocols aren't documented) - Esys (be able to flash new firmware to a control unit or modify settings within a control unit, plus it often contains helpful comments in a mix of English and German that explain what the various acronyms are) - German and American BMW forums (bimmerpost, 1erforum.de); aided of course by a lot of German <> English Google translate

2021 Tacoma Manual owner here (one of the reasons I got it). Gladiators and Broncos are also available with a manual!

> The key point to understand about Bloomberg is that it’s both a software product and a social network. The software product determined who would join the network, but the network is what keeps users there. It’s like a multiplayer video game, or Harvard: Sure, the quests and campus are useful, but people keep showing up because of the friends they’ve made or the connections they intend to make.

From https://marker.medium.com/why-its-hard-to-kill-the-bloomberg... which has a great overview of this point

> And of course, there was John Glenn, monitored inside and out, blood tested, urine sampled, entire organism analyzed for signs of accelerated aging. Close observation of the Senator suggested that there might not be any medical obstacles to launching the entire legislative branch into space, possibly the most encouraging scientific result of the mission.

From https://idlewords.com/2005/08/a_rocket_to_nowhere.htm, which contains far better analysis of the politics of the STS program than I can provide.

My assumption is that Ceph is just there for easy/cheap block storage, while Lustre is doing the majority of the heavy lifting for the "supercomputing." Ceph file storage performance is abysmal, so it doesn't make sense to try and offer it for everything.

Exceedingly efficient (PUEs of 1.0X) vs cold plate liquid cooled or air cooled. The tradeoff is that mineral oil is annoying (messy especially if leaked but even with maintenance) and fluorinated fluids are bad for the environment (high GWP, tend to evaporate) and crazy expensive. In either case, the fluids tend to have weird effects on plastics or other components, so you have to spend a good amount of time testing your components and ensuring that someone doesn't switch components on your motherboards without you knowing, lest it not play well.

[Cloud and Heat](https://www.cloudandheat.com/hardware/) offers liquid cooling systems that purport to offer waste hot water on the town/small city scale.

> That would be nice. It could even run on top of the GH Actions infrastructure now.

https://github.com/thepwagner/action-update being an example of this (and showing go, docker)

> it seems like part of the overhead in maintaining dependabot is that there is ruby code reimplementing yarn logic

The entire maintenance burden of dependabot is "reimplement logic that package managers already do to determine the update strategy." Using package managers functionality for this would indeed make this a lot easier, though even then package manager support for specific things might not be universal.

That said, it's possibly easier to go to the package manager and say "we'd like to implement/for you to implement feature X that will enable Dependabot as well as the underlying functionality Dependabot was missing, that your users probably already want" than the opposite problem of people asking Dependabot to write a bunch of ruby to re-implement something that already exists.

It shouldn't be automatically sending PRs for nix in the first place, right? Did you enable version updates? You can turn security updates off via https://docs.github.com/en/code-security/dependabot/dependab...

FWIW, I don't think security updates are turned on by default anymore, so new repos won't have this problem.

To be fair to Dependabot, Nix isn't supported, so I'm not sure how the PRs could be right?

Lol truly.

The short answer is that the Dependabot team can't support all the ecosystems people want without hiring a dozen engineers who have expertise in those ecosystems. The best choice IMO is to move to a model where the community (and ideally the package manager maintainers) can implement their own updaters (ideally using the package manager directly, so support for yarn whatever can just be "update the yarn Dependabot updater to use the newest version of the yarn updater" without the Dependabot team having to care). GitHub even has a platform for running untrusted code, so...

Disclosure: was once my problem, no longer :)

Totally agree on all points, I'm just letting folks know the recommended solution if they choose to use Dependabot.

As a side note, automerge is... complicated. I've always felt that having it means that people will be mad when it does something bad (e.g. automerges the inevetible npm credential theft update), and they'll be mad if it doesn't exist because they're so sick of the unending stream of PRs, so you're kind of damned either way. At this point, I fall on the side of "let people do the unsafe thing so they shut up about not being able to do so" but that's not the side the security team generally falls on.

Disclosure: one time PM on Dependabot

> This plus the fact that Dependabot is not able to update Docker Compose files at this time.

https://github.com/dependabot/dependabot-core/issues/390 upvote and/or implement it as a fork and run it in an Action.

> The other problem that I have is there is no easy way (probably for good reason due to potential abuse) to manually trigger Dependabot. So Dependabot might run once a day or not do so for quite a while.

There is, it's just hidden in https://github.com/:org/:repo/network/updates > click "last updated ..." and then click "Check for Updates" and it'll start a manual run.

Awesome, glad to hear, would love to take a look whenever it's available! Looking at the docs it seems like the current state of the product is much more about subscriptions than usage based billing (e.g. no aggregation or rating). Any plans to add those in?

Nit: there's a lot of noise being made in comments about it being an open source product, but I haven't found the source (maybe I have to speak to an expert to get it?). github.com/getlago has the docs, which is nice (and gives a lot more info than is available on the website about how the product works), but not quite the same.

Also note:

> Our open-core version is forever free. We will introduce paying add-ons in the future, with a consumption-based approach.

A long time ago, I was the PM on Firestore security rules, which was intended to solve both of those issues.

https://github.com/FirebaseExtended/protobuf-rules-gen was the closest we got: declaring types as protobufs (because Google, of course) and then generating both security rules to guarantee validity as well as client types that would match. I wanted to add proto annotations to do additional validity (e.g. add a regex to validate the phone number string was correct, do length checks on strings, etc.), but we never quite got there (not sure proto annotations are a thing externally either).

The short answer is that backend rules engines, either in their own DSL or bolted on to e.g. SQL, are pretty tough to get right, and have a super steep learning curve. IMO, AWS API Gateway with Lambda Authorizers get this most correct: it offers a programming model that people are familiar with (writing code to access external resources to make the authZ decision) with a clear performance tradeoff (ability to cache the result for a period of time).

Crusoe | SWE, SRE, Hardware/Firmware, Networking | ONSITE SF Bay Area or Denver/Boulder | Full-time https://crusoeenergy.com and https://crusoecloud.com

Crusoe is hiring engineers to build a high performance, carbon negative cloud platform. We're a series C company (just raised ~350MM @ 1.75B) with a growing engineering team (currently ~15) looking for folks to align the future of computing with the future of the climate.

Our stack: GCP, K8s (and related ecosystem), go, Typescript and React frontend.

Job descriptions: https://www.crusoeenergy.com/careers

Feel free to email me at: mike at crusoecloud dot com if you're interested!

Throwing that natural gas through a generator and an exhaust system is even better (more "net negative"). Compared to flaring, you can achieve a ~98% methane reduction and a ~60% CO2e reduction (source: https://www.crusoeenergy.com/digital-flare-mitigation).

Disclosure: I work for Crusoe Energy, who's goal is to eliminate routine flaring and align the future of computing with the future of the climate. We colocate data centers serving crypto miners and a high performance GPU cloud (crusoecloud.com). Our GPUs are indeed "carbon reducing", offsetting the emissions of a car over the course of a year.

Really good article on zoning in Japan: http://urbankchoze.blogspot.com/2014/04/japanese-zoning.html

I think it's a bit of both, it's not viewed as as much of an investment therefore zoning laws are lax, which mean that housing can't become an investment because anyone can build (up to) anything on a lot.

A long time ago on a BaaS platform I worked on, we dealt with an IoT company that pinned certs and when we rotated them they had no way of updating their devices... I think we had to put them on their own server and just left the old cert running forever. As the sibling comment here says, "I doubt a random IoT company does stuff the proper way..."

Hate to say it but have you tried turning it on and off again? IIRC sometimes the state of alerts got stuck in a weird place and resulted in the incorrect state. Toggling it might put it back into the desired state.

I'd also check and make sure Updates is turned off (delete the dependabot.yml).

That's how everyone does it today, but given that GitHub has an issues product, it really should be better integrated.

The main issue is that issues are publicly viewable, while security alerts are only available to certain users (e.g. repo admins). Since repo owners of e.g. popular OSS repos might not want public issues around their security vulnerabilities, this isn't something that's been actioned.

Should GitHub offer more granular permissions on issues to resolve this? Probably, but unfortunately that's reaching fairly deep into how GitHub works today.

(Disclosure: former Dependabot PM, no longer at GitHub)

I don't think it's too hot a take, but it is incorrect. Dependabot Alerts (and Updates) are required on all internal services and folks use them (and provide similar feedback).

Dependabot Alerts is working on some of these things, starting with e.g. https://github.blog/changelog/2022-02-08-dependabot-alerts-p...

I know that security alerts in general are working on ways of assigning alerts (or opening issues that reference those alerts)--hopefully this is something that will show up soon.

(Disclosure: former Dependabot PM, no longer work at GitHub)

Crusoe | SWE, SRE, Hardware/Firmware, Networking | SF Bay Area or Denver/Boulder | Full-time

https://crusoeenergy.com and https://crusoecloud.com

Crusoe is hiring engineers to build a high performance, carbon negative cloud platform. We're a series B company with a growing engineering team (currently ~15) looking for folks to align the future of computing with the future of the climate.

Our stack: GCP, K8s (and related ecosystem), go, Typescript and React frontend.

Job descriptions: https://www.crusoeenergy.com/careers

Feel free to email me at: mike at crusoecloud dot com if you're interested!

> It would not be profitable to convert that natural to electricity if it was used for anything besides Bitcoin.

My sibling comment talks about this a little more, but as someone running data centers on the same technology, I can assure you that it is possible to do profitable compute that is not crypto mining on this technology.

> "The firm estimates that bitcoin mining allows carbon dioxide-equivalent emissions to be reduced by over 60% compared to routine flaring."

https://www.crusoeenergy.com/digital-flare-mitigation has all the stats on Methane, CO/CO2, VOCs, NOx, etc.

For comparison, using one of our GPUs for a month offsets the equivalent of ~400 kg of CO2, which is about the same as a round trip flight from SFO to SEA.

Coming in a bit late to this (apologies for missing HN yesterday), but I'm the product lead for Crusoe Energy's cloud product--we're in an alpha of exactly this :)

We've got Nvidia A100s and A40s racked in data centers on site; ML training, rendering, simulation, etc. are all great applications for this type of data center.

If you're interested in learning more, crusoecloud.com has some info (plus a signup page), and I'm also available at mike at crusoecloud dot com.

Howdy, I run [Crusoe Cloud](https://crusoecloud.com/) and we just launched an alpha of an A100 and A40 Cloud offering--we've got capacity at a reasonable price!

If you're interested in giving us a shot, feel free to shoot me an email at mike at crusoecloud dot com.

Which providers were you looking at? IIRC Huawei was the only company providing ISO container DCs, but the were super low density (e.g. 50kW total) compared to what the original Google/Sun/HP designs were.