thecombjelly

A potentially good idea got corrupted by vendors, password managers, browsers, etc trying to assert control. I'm also an engineer and I find the UI around passkeys entirely unclear, but it doesn't have to be that way. It seems like everyone wants to be _the_ password manager for all your passkeys. They don't want to make it easy to understand that is what they are doing though, they just happily offer to "handle it for you".

My non-technical friends are extremely confused by passkeys and if they should use them and how to use them and I honestly don't have very good answers. It is a mess. I don't believe an inherit mess, but one created by the companies and projects trying to take advantage of the new system.

Very cool project! It looks nice and the technical aspect of how sharing/CRDT is implemented is a really great idea! I would definitely be interested in the ability to change the relay; ideally to something self-hosted.

Opt Health | Mid Full-Stack Engineer | Remote | Full-Time | US

We are a small startup focused on creating optimized health outcomes by connecting patients to doctors and supported by regular lab testing. I'm hiring to build out our core engineering team, which I lead.

* I care deeply about creating a healthy work environment that supports and enables all team members to meet their own goals

* Opportunities for mentorship from a small but very experienced and skilled team

* We greatly value diversity and seek to build and understand from all perspectives

* We value high-quality, sustainable work

* JavaScript, NodeJS, React, Postgres

* You have at least a few years of experience engineering web applications at small companies

* You would enjoy the challenge of helping to improve a difficult codebase :)

* You would be ok working under HIPAA compliance and dealing with health-related integrations

* Salary $130K+

Interested or questions? contact: thomas.hintz at getopt dot com

Looking through the docs it seems a very nice lisp. Clean, simple, yet covers all the basics without a lot of legacy warts. let with less parens and limitless if branches are very nice. Definitely one of the nicer looking JS lisps I've seen.

I think you make a great point. We _should_ question whether it's a good idea to make the word processor. I'm not saying it shouldn't necessarily be made but we should think about how it can be used and if the potential for harm is too high or if it can be mitigated. My point is these things should always be kept in mind and we need to not be afraid of not making the technology.

This is abuse and wrong. Just as it is abuse and wrong for every website or app that does something similar. And this couldn't exist if we as software creators didn't make it. We as the creators of software need to look at everything we create for its potential to be used against people and if it could potentially be used to abuse someone, like say exposing interfaces that can be used for biometrics, we need to refuse to make it. People have survived for ages without your software and they might be better off if it stays that way. Don't be a part of this.

SEEKING WORK | San Francisco Bay Area | REMOTE-only

I'm a Frontend Javascript web consultant specializing in React.js. Whether you're just getting started with a new React app, or transitioning from a different architecture, or in the middle of React development, I can help. Unlike many others I also have product management and founder experience. This helps ensure that the technical side is addressed while also meeting your business goals.

I've worked on Frontend heavy web applications with millions of monthly uniques as well as prototypes for startups. See some of my work here https://thomashintz.org/my-work

More info: https://thomashintz.org

Contact: contact [at] thomashintz.org

* Note that I typically work on a flat project rate with a minimum of $5,000, and most projects in the range of $10K-$70K. If the scope is undefined or the project is open­ended, I’m open to a weekly rate as well.

I do all my browsing with uMatrix with everything blocked by default but first party CSS. It really makes the internet a more enjoyable place to be. Pages load much, much faster and it's often easier to find and read the content. On mobile it saves a boatload in bandwidth costs. For example, loading a NYTimes article takes 90KB and DOMContentLoaded is in 69ms. Truly much of the other stuff loaded is bullshit because a significant amount of the web is more usable without all the crap.

I agree on "Left hand of darkness". "The Dispossessed" really is excellent though.

This seems like a good time to question if we really should have cars at all. Autonomous cars might be better in some ways but they are still tons of metal flying at high rates of speed. Accidents will happen and people and other animals will die on a regular basis. Cars also require tons of infrastructure that walking and biking don't. You also have the environmental destruction of GHG emissions and from the mining of rare metals needed for batteries, you have roads and parking lots destroying habitat and using up valuable space, air pollution and smog from tailpipes or energy generation, noise pollution, and more harmful effects. Autonomous cars might mitigate some of those things but most of it will still be there (or we'll just use cars even more and so we'll have just as many deaths total along with the rest of it?). What about doing research and testing a world without any cars? It will probably be a better one.

They could but if part of the process is proprietary or hidden how can you know what it is doing?

Do programmers love numbers and algorithms so much they want to be reduced to them? Programmers are people and should be treated as such.

Also, shouldn't we be concerned that giving one company's algorithms control over who gets hired will be too much power in too few hands? And algorithms are not neutral. The people that make the algorithms have biases and discriminations just like regular people do but at least if your company does its own hiring you can work on figuring out what those are and how to address them. How can you do that if you depend on some proprietary algorithm?

And what about disabilities? How does your algorithm handle those? Racial bias? So many unanswerable questions.

I have many issues with the way most companies interview but giving up that process to a proprietary algorithm seems like the worst solution. This is not news to be celebrated.

Why are we still making appeals to corrupt politicians? We might not control the cables but we do control the content. Why don't we shut it down until we get what is right? Why not another SOPA blackout and this time it doesn't stop until net neutrality is safe?

At that point it seems you would have just promoted politicians in to the capital class without the middle-person, but again they now represent the capital class and all their non-politician capital class buddies at the cocktail parties, instead of representing those without much capital.

Yes, it fluctuates depending on numerous factors, including how unhappy those without capital get about the unequal distribution of capital. You see this when monopolies start getting broken up and some wealth gets passed back down. But inevitably the capital gets concentrated again because that's how capitalism works. And even when some of the wealth gets passed back down the people in power generally stay in power.

America has a capitalism problem. What the article fails to address is that the root cause is really capitalism. Under capitalism wealth and power always concentrates, which in the case of businesses, that eventually means bad monopolies. Under a representative democracy that also means politics will always be corrupted because those with money and power will always be benefited by controlling politics, and they have the money and power to do so (who owns the news media? who can afford to buy off politicians, whether they start corrupt or not?). While the power of monopolies ebbs and flows as those without capital get angrier, the monopolies will always come back because that's what capitalism does.

Monopolies are not inherently bad. It's entirely possible to have a monopoly and have a great thing that everyone likes and is happy with and which keeps innovating. But under capitalism the primary incentive is the accumulation of capital which rarely lines up with creating something great long term.

Alternate proposal that would not destroy more of the earth, make a big impact on lessening climate change, and improve people's health: ban personal vehicles from urban and suburban areas. Then reallocate the resources from maintaining roads and sprawling infrastructure to mass transit, biking, walking, and new housing. Roads and suburban infrastructure take up an absurd amount of space that could be reallocated to housing or even more open space. It would also help tremendously if property owners were not allowed to have any vacancy. A ridiculous number of housing units are sitting empty that could be used.

and ask him what should be cut

Or her.

What do you mean by better code? Good design is totally different than small tweaks and style changes. I'd argue putting in the effort to learn how to create good designs is the best way to write better code but it takes a lot more time and effort but more than pays off in the long run.

And there is no silver bullet. Advice like "Strong typing" or "functional programming" are not always going to be the best code for the task at hand.

* Programming languages

* Software development methodologies, things like Mythical Man Month

* Computer Science history and basic theories and concepts

* Compiler implementation techniques.

* Anthropology and related subjects. Programs are written by people and for people so understanding people helps a lot.

The biggest thing is to approach things from all perspectives and an open mind. Learning programming languages of different types is great because the different language families highlight different techniques, concepts, and ways of thinking. No one approach or language is the perfect solution to everything. Try to aim for the largest perspective: functional, homioconic, machine like, pure OO, strict, lose, etc. You can look at the lineage of programming languages and what developed and derived from what and learn one from each group to get the broadest perspective.

Learning CS history and basic theories might not be directly applicable to your life but the knowledge that comes from it will show up in everything you do and knowing how to leverage it makes a big difference.

The value in learning about compilers, GCs, etc comes from being forced to learn, in depth, languages themselves and concepts behind them. If there was anything you didn't learn in depth in other areas they will probably show up here.

Everything you learn about programming and CS is ultimately dependent on humans and how we interact with computers. Understanding how we think will help you develop long lasting programs that are easier to understand and use.

Depending on your goals it may be useful to learn about the basics of how the hardware works, although that is more related to performance optimization than good design and good code.

Edit:

Learning about so much is a long process and never ends but if you want to write solid code long term, and not just do what's popular at the time, it's the best way to go. Just take it slow and do it at whatever pace works. It works best if you have toy (and not toy) programs to make in each language as you go. After you've started getting a broader perspective, in things like programming languages, it all becomes a lot easier and faster. You'll be able to learn completely new languages in a matter of days and be better at them than people that have been doing it for years, because you can break it down in to its fundamental concepts and all you have to do is learn the language libraries and syntax, which also starts coming quickly after awhile.

Don't waste time trying to learn and develop style. Don't waste time studying other code just for the sake of learning how to write better code. Don't waste time reading generic things on how to write better code.

Put the effort in to learning new concepts, programming languages, methodologies, programming language history, computer science, and even broader subjects dealing with humans and how we think and form ideas. There are countless ways to write code and without having a broad knowledge of them you will only at best reach a local optimum and rarely choose the most effective solutions and designs. The worst thing you can do is stop learning and seeing other perspectives.

The OS has not been open sourced yet but will be soon. Personally there is https://github.com/ThomasHintz/ and https://bitbucket.org/thomashintz/ and even more on my personal website http://thintz.com

Technically it could support C. One of the reasons it is based on Scheme though is that there is a lot of code already, code written in Scheme. :)

Many times it is less resource intensive to do manual memory management, it just depends. The sacrifice in performance comes more from runtime features like type checking.

Very true. When it comes to the resource intensive development features in 3L they can actually be disabled. But also this is partially a bet on the future, a bet that hardware resources will continue to become less constrained at all levels. Of course that is not for sure when it comes to that but it seems more likely than not that we will continue to advance in some ways. It's important though to start work now so that we are ready when the time comes.

Regarding batteries, the real issue there is how often you wake up the hardware from low power states. An OS like 3L could actually control that better than what we have today and give us better battery life.

When is the last time you needed a feature that could only be provided by your kernel?

Generally these are "unseen" features such as adding multicore support or adding support for a power saving feature on your graphics card.

How are they going to try things out if your OS doesn't support any of the techniques they're interested in (i.e. novel ways of getting at hardware, novel ways of doing virtual memory, etc)

They are interested in a lot more than that. Check the 3L references page for a few examples. [0] Plus you can do many of those things with 3L.

You realize that this sort of thing is a huge area of current research, right? Because it's a really, really hard problem?

Yes. But it is certainly possible and has already been done to some degree. Genera, for example, did it and a number of other real-world and research OSes have done it. Of course the real challenge is making it as real-time as possible but getting it most of the way there isn't actually that difficult.

[0] http://3lproject.org/references

This still falls within the 3L security model though. A program can only do that if you, the user, allows it.

Also, 3L runs in two modes: development or secure. In secure mode you can completely disable manipulation of source code (or strip it out) and mark all code as read only and have the system verify the code hasn't been modified when it is run.

Right now, not really. PreScheme currently compiles to C. Eventually the goal is to create an assembly backend and if that were combined with incremental compilation features you could manipulate it at runtime to some degree.

3L will support Unicode from the very bottom up.

Yeah sorry my fault really. I'm working on improving the organization of the site and I haven't had near enough time to write everything down in an intelligible fashion. Most things are still in my notes or waiting to be extracted from various papers.

Do I, as a user of the OS gain anything, or is it just easier for the kernel developers to not have to care about that?

Even if you don't gain anything directly you still gain significantly indirectly. Improvements in the speed and quality of kernel development means end users see new features quicker and bugs fixed sooner. It also makes it easier for CS researchers to try things out and make large advancements that can be easily applied to the OS.