1,583 karma · joined July 29, 2013
I'd argue the better parts of systemd (it's not all bad but there's a lot of low-hanging fruit for all of us to gripe and bicker about) are the imaginings that came from launchd. That for sure was more UNIX centric than "linux" in particular.
You're right that the criticism "just become windows" seems weird - if anything else one should just say "get a mac" since that's where a lot of the launchd ideas originated.
Not everything has to be harangued like many federal-level politics are. You can just go to your city council and demand better. The worst that can happen is they say no - and you can just organize to vote them out with the rest of your community.
My problem is that helmet use isn't exactly "well-studied." All these studies look at existing reports from medical centres on injuries & deaths. This doesn't actually account for the broader behavioural changes in the system, or look at causes outside of "injured while wearing a helmet vs. not."
In any other industry this kind of reporting (while factual) is absolutely ignoring everything else. A short list of what isn't being considered:
- Which road and behaviour led to incident?
- Which kinds of road conflicts can be addressed by helmets?
- How did road design lead to the incident?
- Were environmental factors a concern (winter, ice, rain, etc.)?
- How does behaviour for the cyclist change as a result of not wearing a helmet?
- How does behaviour for other road users change as a result of a cyclist not wearing a helmet?
- What kinds of helmets are more viable for protection in the case of the most extreme (and most common) conflict scenarios? How do we then test these helmets to ensure compliance in manufacturing?
These are all questions you'd expect to be answered here, and then you'd do the cost-benefit analysis on whether a mandate is necessary or not. A "well-studied" field would have discussed these effects in broader detail, not just short-cut to "fewer people who already had huge injuries while cycling died when using a helmet." That is not the entire problem, because it leaves out a huge sampling of people who do not wear helmets and do not make it to the hospital in the first place.
That said, it's notoriously under-studied. If you look into "best helmet" in terms of safety you'll see a lot of marketing speak and not a lot of science. The way that helmets are tested tend to 1) not be reflective of actual use of the helmet in a conflict scenario and 2) tend to make pretty broad assumptions about the largest danger factor on the roads.
The thing is that you would /think/ that there's a lot of evidence out there for helmet use. The most compelling evidence for helmet use is for drivers in cars / automobiles, and we wouldn't dare mandate that into existence.
Helmet laws always seem to get people ruffled up but at the end of the day the number of bike fatalities is already low, and skewing that in terms of helmet use somewhat misses the point - dedicated and separated bicycle infrastructure will have a vastly larger impact compared to any mandate on using a helmet. It seems like arguing about adding a mandate on helmets is just an easy way for the system to wash its hands of responsibility for not regulating vehicle and street design more thoroughly.
There have certainly been other contributors <https://github.com/capnproto/capnproto/blob/master/CONTRIBUT...>, but Kenton does most of the development and maintenance on his own.
There are few things I lament more than having to spin up on a new serialization / file format and it isn't using Capnproto or Protobufs or some similar invention. Capnproto has truly spoiled me in terms of how consistent and feature rich it is for what seems like a "simple" task.
> Language-exclusive build chain
I'm not sure I agree here. Bazel / Make / Ninja still exist. Most of the tooling that exists extant to that usually leverage some knowledge of the conventions of both the community as well as actual knowledge from the code itself (Cargo for example understands the module system in Rust). You kind of touch on this by mentioning "language-aware parsers" for dependency management, but this existed in C and C++ long before the JVM came along, so it's weird to place the blame there.
Make has many things wrong with it but I wouldn't say that a "one build tool to rule them all" is something it did well. Even with stuff like CMake or GNU Autotools the final makefiles are almost exclusively used for C projects. I rarely see Make used in any other context, which I'm not convinced is a machination of language-specific tooling rather than some intrinsic property of Make itself.
> Language-exclusive packages and repositories
The proliferation of packaging systems is frustrating, but would you rather learn pip (PyPI) / cargo (crates.io) / npm (npmjs.com) across several OS's and platforms or learn 5 different OS / platform package managers? I know for certain there's nothing like that on Windows!
This isn't the JVM's fault, and I think you're looking at it in the wrong order here. These language-specific package managers and repos are made to make the language run consistently in different environments. Most repository maintainers do not and cannot have the bandwidth to package everything under the sun for every programming language.
> The OS doesn't know how to run your program
Oof. The program you're running is the JVM, which as an input is taking a jar file and as output does some work. The OS knows how to run that just fine. Doesn't this criticism basically disqualify every single useful program that isn't a compiled C binary on Linux? ELF isn't that hard but also I'm not sure we need to tie all our boats to that sail either.
If I'm trying to be charitable, I think you're experiencing a lot of frustration with your tooling and expecting something out of the JVM and programming in general that isn't necessarily true. You may just want to stick to C / C++ and tooling built 40+ years ago, but dismissing most of the tools that people use every day seems a bit "cut off your nose to spite your face."
¯\_(ツ)_/¯
TYPE: Full-time
DESCRIPTION: Careers page here https://grnh.se/2f11aa945us
Tangram Vision is a fully remote company on a mission to enable anyone to leverage the power of perception like never before. We are developing a platform of products that help robotics leaders, engineers, and fleet managers reduce technical debt and understand their perception systems inside and out at scale. First up: sensor calibration, driver management, and plug-and-play streaming for cameras, LiDAR, radar, IMU, etc...
All software engineers are expected to have a deep knowledge of programming paradigms and behavior. All of our algorithms and sensor tech is written in Rust. Our web stack is centered around Svelte, Supabase, and other more traditional frameworks.
Candidates with a background in perception sensors (cameras, IMU, LiDAR...), perception research, driver software, or calibration are encouraged to apply.
- Calibration Engineer: https://grnh.se/4ab40e025us
- Field Application Engineer: https://grnh.se/05b4949e5us
LOCATION: Fully remote, in US time zones.
ESTIMATED COMPENSATION: Market rates in USD dependent on the opening ($90k-$170k), with equity options for all positions. Specific salary ranges for each job are in the posting.
REMOTE: The whole company is fully remote. We have no corporate office of any kind.
VISA: We have no protocol for visa sponsoring at the moment, though we do have employees who hold visas!
CONTACT: Apply to any open position on our careers page https://grnh.se/2f11aa945us
But the focus on work, jobs, etc. and the general assumption that education is purely vocational and only to serve our capitalist overlords is a really dismal thing. We should also make education free as many countries have, so that getting an education isn't about taking out hundreds of thousands of loans as much as it's about having the resources to better one's life.
Chapter 9 is certainly the weakest part of the book but it picks up very quickly thereafter.
[1] https://www.thatgeoguy.ca/blog/2021/03/07/review-the-little-...
Given this is HN, the equivalent in software is: fix the code on your side; don't try to train your users. We don't add warning labels telling users to not do SQL injection, we solve it systematically by making sure our backend isn't using untrusted user inputs directly in queries!
You're right in that warning stickers won't fix stupid, and that we need more systemic action in order to treat the cause and not the symptom. I'll be honest: I don't even know what that systemic action would be in the case of misinformation on Twitter, but I know that warning labels are just a way to shunt responsibility away from Twitter and onto individual users.
Read page 9 in the PDF again - the author goes to good lengths to grapple with this argument and why it is not correct. In particular:
In order to repeat the mistakes of a famous philosopher, one must first
share their beliefs. Now, few people are born with any degree of credence
in the far-fetched propositions embraced by many philosophers. In general,
these kinds of beliefs have to be acquired; and the only way of acquiring
them is to study these authors. It seems that if we wanted to avoid acquir-
ing false beliefs that we would never arrive at except by reading a particu-
lar author, the best thing by far we could do is to avoid reading that
author.Cars are extremely expensive, so if we're comparing car replacements we should look at the total cost. Some sources are [1], [2], if you're curious how expensive cars can be on average.
Flatseal is actually a good GUI client for doing so. It can modify and tweak the permissions that different apps have. Just turn off the network permission and boom - you've turned off all access to the network for that app.
Of course this means your application has to be bundled into a Flatpak or Snap in some way (and the UX for doing this with Snaps is pretty bad IMO), so you'll probably find that your mileage may vary.
Another alternative is to use apparmor and disallow the `net_raw` capability on a per-application basis (this won't matter how your app is bundled) but that can be exhausting to set up individually.
REMOTE - We're a fully remote company
Tangram Vision (www.tangramvision.com) is the Hardware-agnostic Sensor Fusion company. We're on a mission to enable anyone to leverage the power of perception like never before. We believe the full potential of robotics and perception has yet to be realized and that software holds the key to unlocking that potential. We are starting with a platform of products that help robotics leaders, engineers, and fleet managers understand their perception systems inside and out at scale.
- Career pages: https://www.tangramvision.com/careers
- Perception Algorithm Engineer: https://www.tangramvision.com/careers?gh_jid=4003004005
- Perception Sensor Specialist: https://www.tangramvision.com/careers?gh_jid=4014379005
Perception tech stack: Rust! Along with lots of driver code.
Web and Design Tech Stack: Svelte, Typescript + Three.js, Canva
Learn more about us...
- On our blog: https://www.tangramvision.com/blog
- Via our documentation: https://docs.tangramvision.com/
- Check out our multi-modal calibration system, TVCal: https://www.tangramvision.com/sdk/multimodal-calibration
- And our Sensor Fusion system, TVMux: https://www.tangramvision.com/sdk/sensor-stability-and-manag...
- We're also a 2022 RBR50 Innovation Award winner, so we got that going for us: https://www.roboticsbusinessreview.com/rbr50-company-2022/ta...
This company (https://tangram.dev) is a different entity entirely.
There is also Tangram Vision (https://www.tangramvision.com) which is a startup focused on multi-sensor calibration and sensor-fusion. They have been around since 2020, while the other Tangram's out there are relatively newer.
Disclaimer: I am an employee of Tangram Vision.
If anything, I've seen more and more services where paying is just for "premium features," of which getting away from ads isn't one of them. Spotify is a key example - if you pay for premium you don't get ads interrupting music, but you still see their bundled advertisements on the home screen of the app, you get content suggested to you in a way that is very advertiser-centric, etc.
I think we should maybe split off the discussion of "how will these businesses get paid the way ads get paid" from "ads are bad and we should get rid of them." Frankly, I don't care if advertising as a business tanks and that takes other businesses with it. The externalities of surveillance capitalism are pretty shitty, and I'm fairly confident there are other ways for people to be productive within the economy that don't involve the invasive nature of today's advertising ecosystem.
What I'm complaining about above is the claim:
Bitwarden is a superior replacement in every way.
I'm happy to disagree and say that if you want a product that only does vault storage, and neglects all business or non-user/pass combo needs - great, you can have that. But to suggest somehow that Bitwarden is that product and should remain so - well I'm afraid you're not looking at their business model. They already have SSO options (see https://bitwarden.com/products/business/), audit & compliance, etc. I am being very frank about features that are missing from Bitwarden today that actual customers are looking for.
I am a Bitwarden premium user for my personal password management, but we use 1Password business at work.
Some things Bitwarden is missing:
- Integration with biometric auth on Linux
- SSH key types & SSH agent integration
- API token types
- Equivalent to `op run --` in their CLI client
- Shared vault / folder management in Bitwarden is clunky,
especially with CLI
I love Bitwarden, but they very clearly employ fewer people and have fewer features.
The reason that sewage and water is so hard to get right in the United States is in part due to sprawl, as well as the lack of political will to actually maintain infrastructure once it is built.
A bit of a deflection I'll admit but - look at the NY subway. It barely receives the funding to keep basic maintenance afloat. Compared to equivalently sized systems in Europe it fails because there's a massive political diaspora to overcome since culturally taking transit is "for the poors" (you know what that translates to) and we can't be giving them anything.
Similar holds true for sewage and water (for water, look at Flint Michigan). Housing, transportation, zoning, etc. are all the same problem. The reasons we fail at them are all connected and without taking a holistic approach we likely will remain bad at it. Pointing to any one thing and claiming "well even if we do that we'll still suck at 99% of everything else" isn't really a helpful description of reality, it just means there's more work to do.
I guess what I would really push back on in your argument is the point that higher density requires higher competence. At some meaningless level, sure, we have engineers that have to solve harder problems. But the reasons that the US is bad at a lot of urbanist policies isn't because we lack competency (you could just hire people from overseas) - it's because we've allowed ourselves to build a system that incentivizes that incompetency at multiple levels through restrictive zoning, endless veto privileges a la "community feedback" / NIMBYism, car culture and the social disdain for what is perceived as normal in other countries (trains, bikes), etc.
This isn't a problem with the US geographically or its people, and the problems have solutions. I think if you talk to most people in cities they probably agree wholly or in part on a lot of fronts, even if there's still a prevailing "got mine" attitude depending on where you ask.
I even learned today that irssi has an OTR module by default! On Debian systems you have to install irssi-plugin-otr but once you have that and irssi you can just `/load otr` and `/otr init` in a query and that's it, you have E2EE.
This is handled client side though, so I suppose if your clients cannot agree on a protocol you'll be left with nothing. I'm not sure that's really the responsibility of the server though, since we're talking E2E after all.
As an observation I'd agree. However, my impression of the parent commenter was that they implied that 5-10mph over the speed limit is the correct way to drive. Were that true, why wouldn't we just set the limit anyways? How did that limit get chosen?
Again, this goes back to the 85th percentile - the ways in which we decide how fast to go on a road or street are wrong. Of course, there's two things going on in this thread:
- Using tech to warn / limit drivers from being able to speed over an agreed upon limit.
- Engineering our roads so that the intended speed matches the prevailing speed of traffic.
Now I'm more in the second camp on this one than the first, I'll admit, but I don't think that we should just sit by and accept "some people speed, therefore we should all go faster" as a given. I have definitely witnessed people going 85+ MPH, especially if you're on an interstate far away from any city. However, this is not the norm and not really where the tech in TFA is going to be deployed.
Either way, the issue I take is with moralizing going faster than the speed limit. You might say it's the flow of traffic, but that just smells like justifying something that most drivers already want to do (go faster), instead of understanding the action (speeding) and its effect on the environment around us (increased danger, increased fuel consumption, increased noise pollution, etc).
That's a couple things:
1. Not based on any actual design criteria for the road
2. Assumes that 85% of drivers are somehow more knowledgeable than the engineers who are supposed to be designing our roads and transportation.
The claim that you should be always able to go 5-10mph above the limit seems to be a mythos invented in and ingrained in the fabric of the American psyche. Better approaches exist than to just pick a popularity consensus from a sample of random drivers in a study (who are predisposed to going faster, often because the study is done before full levels of traffic set in).
[0] https://www.strongtowns.org/journal/2020/7/24/understanding-...
It's not like it needs to slam on the brake, it just needs to disengage acceleration past a certain speed. This isn't new grounds for tech and it is _currently_ deployed on our streets.
I'm not sure what the panic over this is, if anything this is a good thing - why should passenger vehicles go 200+ km/h anyways? Why isn't a more reasonable limit imposed, for cars that spend 99% of their time in an urban centre? What actual road is engineered to even support that kind of speed?
https://thewaroncars.org/2022/05/31/two-wheels-good-with-jod...
I recall the K-9 developer needing additional funding in the past, so this is great news for that project [0]. In addition, I'd much rather use "thunderbird" on mobile as an extension of K9, since it has thus far been my favourite mobile client. Work in the most recent years has been wonderful, and it's a pleasure to use (although I've vastly cut down on mail on mobile because hey, a keyboard is better).
Overall, this seems like it makes a lot of sense. Hopefully this will mean that the shift to supporting a mobile client won't detract from the good stuff desktop Thunderbird is doing as well.
It's definitely not the norm compared to many of the other listings in this thread but it definitely gave me a better understanding of many algebraic properties and helped build an intuition around spaces, vectors, products, etc.
It doesn't have a ton of graphics, to which you might snub your nose at it (you mentioned visual learning), but the graphics it does have are incredibly useful for building a geometric understanding of what linear algebra concepts map to. The subsection on quaternions and pseudoscalars is one of the best descriptions of such in my experience.
Take the "defer" keyword in GNU C - it's valid in anything that has the GNU extensions but isn't standard C at all. And yet, some projects swear by it (it's not a bad feature, just nonstandard).
There's a lot of weirdness in C implementations even looking across LLVM, GNU, or even when picking which libc you want! Try porting any nontrivial project to work with musl-libc. You might find that it's not as easy as swapping in a target and building statically!
This is perhaps the whole rub with standardization - it's bought us as developers a lot, but it doesn't cover everything. The veil was kind of lifted for me when I started trying to use different Scheme implementations in a "standardized" way. I eventually gave up on that and just use whatever implementation I am most happy with (often CHICKEN, but that's a digression).
This gets more complicated with C++, which modern standards mostly requires C11, but then also doesn't support everything that C11 requires either. They're different languages but yeah, compilers are gonna disagree on some of the edges there.
[1] https://github.com/Rust-GCC/gccrs
[2] tangentially, Rust also avoids some UB discussion because the type system is a bit more complete in terms of its properties than C is, so they can resort to Option or Result when things get dicey in an API. Further, there's no official Rust ABI unlike C, so you don't have to worry about that either...
Of course, it's not as much of a free-for-all as some other networks (I recall Rizon lets you set whatever cloak you want), but it should hide hostnames.
I don't disagree! The notion of state vs. time snapshots in terms of the mental model seems like it might be missing something small but sounds mostly on the mark? E.g. in dynamic languages my REPL is more of a debugger than any actual debugger could be.
> * I don't actually know if there are programming practices that center around managing moments in time. I can't even think how that would work, but I would be very interested to know if there are any :)
I think this depends on how you abstract control flow. Actor model comes to mind, as Smalltalk really doesn't have this notion of "time" in the same way. You debug live in such a system, and "time" is more a matter of what abstraction sent or received something (and as such may have failed). Similar arguments could be made for conditions / restarts in Lisp, perhaps even more strongly, since you can manage errors through conditions and then restart code (going back in time, so to speak) in a sort of live-debugging way. Not sure it measures quite to the degree you were asking, but that's the first thing that comes to mind.
Another thing is the movement towards async-await / cooperative coordination in programs. Even if you ignore concurrency, designing code in a way that coroutines cooperatively yield to one another (e.g. generators in Python) helps sort this out too. Basically, you make "time" in a program a function of control flow, and do that by forcing an abstraction where you explicitly yield control in the program. This relates to both the actor model and conditions / restarts in Lisp, so I feel like I'm pulling on the same train of thought there.