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

Notice that most of the examples have none of the green highlight counter, which is shown for

> small losses. KEEPING SCORE: The Dow Jones industrial average rose 32 points, or 0.2 percent, to 18,156 as of 3:15 p.m. Eastern time. The Standard & Poor’s ... OMAHA, Neb. (AP) — Warren Buffett’s company has bought nearly

the other sentences are in contrast to show how specific this neuron is.


The highlights are better visible in this visualisation: https://openaipublic.blob.core.windows.net/sparse-autoencode...

There are also many top activations not showing increases, e.g.

> 0.06 of a cent to 90.01 cents US.↵↵U.S. indexes were mainly lower as the Dow Jones industrials lost 21.72 points to 16,329.53, the Nasdaq was up 11.71 points at 4,318.9 and the S&P 500

(Highlight on the first comma.)


Ah, that makes a lot of sense, thank you!


> No, it's not. Seeds and even embryos are to DNA what a running piece of software (and especially, a Lisp/Smalltalk image) is to its source code: the latter stores only a fraction of the former.

Thank you for pointing out this similarity. While a piece of software is infinitely replicable - a simple git clone from GitHub would suffice -, the surrounding software ecosystem - compilers, interpreters, installers, linkers, operating systems - needs to be in place, as well as the hardware.


> Interesting. Gets you wondering what else you might not have heard of.

Consider how much of a rabbit hole YouTube can be and then imagine that the subsection of humanity that uses or is able to use YouTube is just a small part of it. A few topics and projects get a lot of attention but there are - I suppose - millions more with a dedicated fan base.


> I keep and grow as much seed as possible. It is the only way to adapt plants to your local environment and farming methods and needs. I get plants that are much easier to grow, then breed for taste or other features. Thats how the heirlooms were created.

Do you actively select and breed the plants you grow, or does the selection happen "by itself" since only plants that are somehow adapted to local condition reach maturity?


Both. I started doing this because my area was populated after industrial farming started. Local adaptation slowed drastically after it was possible to ship food such long distances. Prior to that every food grower kept seed and brought them to new environments. I came to realize that all my seed comes from at least 8 degrees closer to the equator than me that are generally warmer, have a longer summer and are certainly dryer.

Starting with a new plant I will buy a few varieties whose descriptions suit my fancy. Then plant as many seeds as I have space for. Adapting plants is a numbers game. Some won't germinate, some will grow slowly, some will become diseased and some will be eaten by pests. None of those are suited for the local environment. Thin the planting to allow the strongest growers room. It should be obvious which ones to keep. Once you have the plants that started from seed best its time to start selecting for other traits. Traits depend on the plant but for food you should be selecting mostly for taste at first. For example, I am crossing one pea variety selected for wirey strong vines and purple pods and a couple others for taste. This is my third year with those and I am getting sweeter pods on wirey vines but the vines aren't quite as strong or tall. So, I planted some of the original wirey vine seeds to try pushing the line that way more.

Some trait selection is unintentional. The plants are going to adapt to you as well. They will adapt to how you plant, harvest, and save the seed. With my grains some of the plants are too short to harvest with a sickle comfortably. Those go in the eat or feed to chickens pile. Some also don't separate from the plants when I thresh by hand. Also to the chickens. What I am left with are seeds that were easier to process just by not being super careful to get everything. With biennials or clonal root crops you will also unintentionally select for plants that store well as you have to keep the roots over winter to plant them in the spring.

I started saving seed about 5 years ago so nothing has really stabilized into something that could be considered a new variety. But, I have seen the steps closer to my goals.

Purchased seeds are a narrow part of that plants gene pool. If they are open pollinated they were bred until most of the produced seeds make the same looking and tasting plant in a specific environment. Really, if you are gardening, you should learn how to save seeds unless you have a seed grower near you. If you save seeds you will also have more seed than you know what to do with.


> It's a shame, really, because DANE would've fixed so many problems.

It would basically make services like Let's Encrypt unnecessary and would move us close to a world where email encryption and validation works by default.


It would take us to a world where the only CA you can and have to trust is the TLD operators and their nation. Where transparency is mostly an afterthought and violators can't be forced to do anything.

DNSSEC sucks ass.


Some applications make use of this macOS feature, like CheatSheet or Shortcat. I wish other platforms had a similar feature, I only know of vaguely similar behaviour in Vim/Emacs which which-key.


Restricting read access is one of the missing features in monorepos. While they make a lot of stuff easier and trackable, I don't feel comfortable having every temporary consultant having access to all code at once.


Some stuff I'd love to see implemented:

- Typed inputs and IntelliSense. There is very basic support for types, even so, I'd love even more strict types and type inference as in Typescript, so my terminal and shell can give me a hint what kind of input the command is expecting. At the same time, IntelliSense should tell me what command flags are still available and what are viable inputs, like cd suggesting only directories, or kubectl --namespace suggesting available namespaces.

- A concept of past commands as building blocks and/or interactive data wrangling. Many times I am mucking around in zsh to find a chain of commands that reliably gets the data I need out of some CSV or other source, retyping the same few commands with some new links until it works the way I want it to.

- A command like EXPLAIN in SQL so I can see where I should rethink what I am doing so I can refactor that part of the chain. At the same time, I'd love it if I could take one of those magic snippets from Stack Overflow and have an EXPLAIN-like command pick the components apart and explain the flags via some structured docstring format.

- Snippets in the Shell for some regularly used patterns of command chains.

- The concept of transactions, like in SQL, so I can run a command or script without worrying about it failing halfway through - the shell automatically undoing its changes. Maybe this should work on the level of a shell session even.


Marcel (my successof of osh) supports using past commands in a few ways:

1) Command recall, like any shell.

2) Edit of a previous command, giving you access to the command in $EDITOR.

3) Abstraction. For example, suppose you want to find all files recursively, looking for those changed in the last 3 days. You could write:

    ls -fr | select (f: now() - f.mtime() < days(3))
To turn this selection into a reusable command:

    recentN = (| N: select (f: now() - f.mtime() < days(int(N))) |)
This is basically a function on a streams, that takes an input N, and filters for files that changed in the last N days. To use it:

    ls -fr | recent 3
I don't understand what EXPLAIN would do. In SQL, EXPLAIN helps you see the actual implementation chosen for a non-procedural statement. Marcel, nushell, etc. have no optimizer, so there is no invisible execution plan, that would be made visible using EXPLAIN.

Transactions: Might be feasible with a shell built on some kind of COW filesystem, but I'm dubious of how much transaction isolation is really possible even then.


One of the largest holes in encrypted communication is still the fact that the vast majority of email is still neither digitally signed, nor encrypted. And even if they are, the usual schemes do not encrypt the subject line.

I wish there was something like Let's encrypt but for email. Just make it trivial to sign and encrypt your mail. Also, mail clients should give a huge warning for unencrypted and/or unsigned mail, just like browsers do with web sites. Right now, at least on Outlook for macOS, you only get a happy green padlock on signed email, if you ever receive one.


I think Latacora's (famous?) post[1] sums the situation up here nicely: email is designed in such a way that precludes an encryption scheme that actually works for ordinary users. Even power users consistently fail to use email encryption correctly.

If we care about secure communication, then we should be nudging users towards protocols that enable encryption, rather than fighting against it. For 99% of cases, that probably means Signal.

[1]: https://www.latacora.com/blog/2020/02/19/stop-using-encrypte...


I don't think that Signal is a proper substitute for anything that email is used for. Maybe it would be better to work on more secure successors or extensions to email.


Lots of people, including my parents, use email as an asynchronous messaging platform. For those people, Signal is an eminently suitable replacement.

As the post points out: email cannot be extended into a secure position. Attempts to do so either fail to interoperate or fail outright.


Email is also an archive of communications with vendors, shops and government departments.

Signal doesn't let you migrate chat history to your desktop.

Trying to migrate between phones while retaining your Signal history is too hard for most people.

Signal is not at all a suitable replacement, and I believe that forward secrecy is an anti-feature for an email-like usecase.


You know you're in trouble when people start talking about forward secrecy being problematic. What you're saying about the "email-like use case" for cryptography is that it's unserious protection, because a lack of forward secrecy practically guarantees full decryption of the entire history of messages, for any ordinary participant in the system.


A major goal of an email-like system is full decryption of the entire history of messages.

Same as it's a feature of my filing cabinet that items don't incinerate themselves whenever I move house.


Sure. Because people overwhelmingly aren't relying on the security of their email; it's overwhelmingly stuff no adversary would care to read. Then they retrofit the UX requirements they have for those boring mails onto all emails, and suggest that encrypted email should just accept those as constraints, and then we'll declare victory.


>a lack of forward secrecy practically guarantees full decryption of the entire history of messages, for any ordinary participant in the system.

Can you elaborate?


Eventually a private key will leak, and without forward secrecy, that private key will probably decrypt all past messages to that person, and all future messages to that person, until they give all their correspondents a new key.

With email, because people quote when replying, you'll get the other side's messages too.

Like, the simple PGP-like system where sender encrypts message using recipient's public RSA key.

And of course it's not improved by switching from RSA to ECIES.

You need to ratchet the key, or double ratchet like Signal protocol.


Email as a concept can evolve. We can break backward compatiblity. Call it email v2 and include some killer features. If enough major players and users get involved then it'll happen.

My hope is it'll be something like Dark Mail, yet with a carve out for enterprise recipients to inject their controls and anti-malware before end-user delivery. (To combat spam and malware.)


In theory the giants that already hold the vast majority of all email communications - like Microsoft and Alphabet - are in a prime position to introduce a successor, hopefully this time with a receipt so the last argument in favour of fax dies off. At the same time, they have no proper motivation to do so.


That’s the point about interoperability. If we’re going to make “email v2” (not a terrible idea!), then the considerations that will go into securing it will ensure that it’s entirely incompatible with the thing we currently call email.

In other words: without sufficient clarity, email v2 just confuses people like my parents. Who would be better served by Signal anyways.


Vendors big enough to be known by your parents are sophisticated enough to paper over the differences and make it seamless. (Where possible)


“Where possible” is doing a lot of work!


Signal has no concept of trust delegation: also, the verification API is extremely hidden and sucks (i.e. my brother working at a FAANG had no idea it existed or what it did - it's also extremely confusing when you open it).

This creates two problems: (1) is that Signal functionally operates as "trust on first use", and (2) Signal has no system by which you can communicate to "conceptual entities" - i.e. companies. There's no way in Signal to talk to say, a bank or a government agency as an entity (IMO: to turn a profit, this is the business Signal actually need to be in).

Which makes it a bit of stochastic security measure: encrypt enough communications and probably when something important does come up, the window to intercept it has failed - except of course, that those verification number messages nobody knows what to do with and so they ignore them.


> (2) Signal has no system by which you can communicate to "conceptual entities" - i.e. companies.

This has always kind of bugged me with email as compared to physical mail: While with a physical mailbox I can write a letter "to whom it may concern" and throw it in, with email I need to find out if the special, general purpose inbox is info@, contact@, hello@, or whatever other address the company uses, assuming they use the same domain for their email as they do for their website.

On the next level, there is no first-class support for stuff like 'send this message to person X, although it is adressed to organisation Y, where X works.' Basically, acknowledging the legal and organisational reality that while (single) humans might read, process and respond to communication, it is the legal entity that is actually being adressed.


There is a standard for this, most US companies I encountee over 100 people seems to support at least the security, info, postmaster, and support mailboxes at least.

https://www.rfc-editor.org/rfc/rfc2142


I agree that the verification UI sucks. I have similar stories about otherwise technical people not knowing about it or otherwise not understanding it.

At the same time: the relevant comparison here is email. Email isn’t even TOFU between arbitrary identities; it’s trust-on-each-message. Similarly for conceptual identities (like a bank’s catch-all address).

(I also agree with your point about this needing to be one of Signal’s businesses. WhatsApp and other chats already do this, I believe.)


Email these days is however tied to DKIM and domains. We have UI problems, but communicating to a companies email servers at their domain name can be reasonably expected to be communicating with that company.

It's just the security story on that if you never want the content disclosed isn't great, but conversely, conceptual entity communications are always going to be a bit public by nature.

There's a whole other rant I have about this problem, where we really lack domain specific trust standards - i.e. communicating with a business, what I want to know is "is this a recognized legal business entity in it's jurisdiction, and what's it's status to mine?" which is very different to "I need to make absolutely sure me and John Smith's communication is just between us" - but they're in the same space of problem.


> There's a whole other rant I have about this problem, where we really lack domain specific trust standards - i.e. communicating with a business, what I want to know is "is this a recognized legal business entity in it's jurisdiction, and what's it's status to mine?"

I have the same pain, but this seems more like a regulatory issue than a technological one. Here in Germany, (basically all) legal entities need to publish a physical adress where they are reachable, it would be easy, in theory, to extend this to a reachable domain or email adress, thereby giving a guarantee, at least in Germany, that you are interacting with the business you are expecting. As you said, DKIM already exists.

Unless I have missed your point, then rant away.


DKIM is an anti-spam tool, not an end-to-end encryption tool (obviously, it's not end-to-end at all, and if you're relying on it, you might as well forget about message encryption, because you've simply decided to trust your server).


I agree with the sentiment, but I question how useful this would really be. Most people nowadays unfortunately use web clients, so the keys are going to have to be stored somewhere else, since backing up a browser's local storage is no easy task. If you don't have sole access to keys, but rather the keys are controlled by the same entities that control your email, I don't think there will be any benefit.


I have similar doubts as well. Especially considering that digital signatures and encryption do not protect against impersonation attacks, like phishing via facebok.com or other similar sounding domains, in either the case of websites or email. But without widespread use you don't even have the option.


There are plenty of email users on IMAP, and they use web mail to host mail storage. The IMAP clients can do S/MIME (or PGP I suppose).

The bigger problem is trustworthy user discovery service i.e. a directory to exchange public keys. This exists at an enterprise level (active directory) but not globally.


Usually anyone that buys into the viability of PGP email will also tell me with a straight face that the MIT keyserver is completely appropriate for civilians.


Search is another problem, because instead of simply being able to rely on server-side full text search, every client needs to download all mails, decrypt them all and then create and maintain its own local search index.


This is actually the best example for why encryption isn't a human right. Postal mail isn't encrypted, telephone calls aren't encrypted, and the UN hasn't made a declaration about that. Why is that?

It's because encryption is a red herring. The theory that encryption is going to stop government surveillance is ridiculous. Even a perfect technology is not going to override national politics. Any government oppressive enough to require surveillance of its citizens will not be stopped by encryption. They will just block it or require a backdoor, or find yet more exploits that they won't announce in order to take advantage silently (whether it's the government directly, or one of the many 0day-for-pay players)

Either way they will enforce their will, until the citizens reform their government. You can't tech your way out of politics. You want an end to surveillance? Then go get involved in politics! Force your government to stop surveiling its citizens! Don't wait for someone else do the heavy lifting for you.


Postal mail isn't encrypted because it's not viable for ordinary citizens to encrypt physical mail.

However, tampering with mail, or opening someone else's, is a federal crime with harsh penalties attached. The message is clear: "postal secrecy" is highly valued.


However, tampering with mail, or opening someone else's, is a federal crime with harsh penalties attached.

...and yet the government can still do that if it truly wants to.


I'm pretty sure Skiff encrypts everything


Hello :)

Skiff cannot access email content, subject, and header info. To/from/cc/bcc fields are not stored end-to-end encrypted, though.


I always disliked that it was so difficult to interact with Word if you wanted to create automated documents. Instead I'd love it if there was a developer-first experience to create standardised documents from nice looking participation certificates, invoices, memos, documentation up to multi-tome histories.


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

Search: