daly

I'm actually looking for local hardware solutions.

Sending every change to everything up to AWS would be wildly expensive both in bandwidth and cash. It would also put all of your data "in the cloud" (aka on other people's computers).

Plus a ransomware attack on AWS would make the backup unavailable.

A small, local device that contains a memory cache could write a DVD once half the cache is filled (double buffering).

A double-sided, double-layer DVD can hold 16GB so an "inline cache" with 32GB could copy and store a DVD worth of disk backup and then write a DVD.

BLU-RAY can store up to 50GB

Instead of a single column with ~25 links there is enough screen space for 2 columns of links, thus ~50 per page.

It could be new2.ycombinator.com

I have seen whole countries "drop off the internet" for extended periods of time. Sometimes it is political, sometimes it is due to a cable break.

Russia has suggested dropping off the internet: https://www.technologyreview.com/2019/03/21/65940/russia-wan...

China has a fairly successful firewall and has recently come out against bitcoin mining.

I can see a country that feels that bitcoin threatens its currency working hard to create a bitcoin firewall. I can also see the firewall being lifted after a change in government.

If the country re-joins and its blockchain is shorter than the current chain, what happens to all the transactions? What happens to the coins that are mined within the country?

I can see where a country could have billions of micro-transactions (e.g. coffee purchases) that happen over a single year.

Is it even worth the processor time to process billions of "penny" transactions?

A 10 year chain of transactions would require an enormous amount of time to re-process. Effectively billions of transactions would arrive at once on both sides of the dropped firewall.

Transactions that were "known good" for the last 5 years might not be valid, or at least could take years to validate.

As I understand it there is no central network. So nodes inside the firewall only see internal transactions. Nodes outside the firewall only see external transactions.

As a result, both sets of nodes create long chains based on the transactions they see.

By assumption the BTC transactions are firewalled. Transactions can still happen on either side of the firewall but they are not shared.

Is this supposed to be difficult? If you are a "software engineer" and find this difficult, perhaps you need to find something else to do with your life. This is the equivalent of asking an electrician to install a new power socket.

Not documentation, ... explanation.

It's called Literate Programming.

Just as an example, I tried to cause an LED to blink on a microcontroller. It is a trivial task.

It took me 18 hours. Lots of code to install, several error messages that required hours of google searches, several obscure root-only commands to enable group access, USB recognition, board-specific code updates, etc.

The online video shows that "it just works"... so the expectation is that "it just works".

I did get it to work. But it took 18 hours. Explain that to the boss who watched the video.

Now I'm trying to get an OLED display to work. I'm 10 hours into the game, using an oscilloscope to debug I2C signals... but, but, but, the online video shows "it just works"!

Management has no clue about how complex the whole tower of code required to get anything to work. There is nothing in engineering approaching the complexity of the software eco-system. Nor is there anything that changes so rapidly ... "but it was working yesterday!"

You can't estimate software. Get over it.

In 50 years of programming I found:

(a) time estimate are dangerous. In one case the leader of our team estimated 5 people for 5 months. The company wrote a fixed-cost contract. After 10 people for 18 months the company folded.

(b) time estimates are meaningless. All of the software I worked on was new. There was no "prior art" to ground the estimate. Projects were almost always "late", mostly due to changing requirements.

(c) time estimates assume a known future. Who expected the pandemic? (Or the Spanish Inquisition?). How good is your estimate when the 6 people you could "hire" are all rejects from other projects because they can't program?

(d) time estimates assume a known good tool set. CorelDraw won't run on your old Mac but the company won't pay for new hardware. Microsoft pushed out a "destruction tuesday" update and now your machine won't boot. Somebody "upgraded" the library software and now your code won't compile. And don't get me started about chasing a compiler bug (I've fought 5), each costing an unplanned week. Or hardware bugs (3 times), that basically stopped the project until they were fixed.

(e) time estimates will cost you time and money. Suddenly everything become a crisis. Cancel that vacation. Work nights. Work weekends. Nobody gets a raise if this is late.

(f) time estimates WILL be used against you. Managers write down the "estimate", stick it in a drawer, and when "blame time" comes you can be certain to be "to blame" for a bad estimate.

I know you think I'm wrong. You "just know" my "lived experience" is nonsense.

You can't estimate software. Get over it.

Read "The Mythical Man Month".

Congratulations. You are the 10,000 person to propose infix for lisp.

Hydrogen makes steel brittle. News at 11...

Suppose you wanted to attack encryption using keys created on a laptop or desktop.

For "strong keys" in certain forms of encryption you'd like to create 2 "random" primes that are of about equal length. This greatly reduces the space.

Given a pile of machines it seems that a feasible attack would be to "randomly" generate primes clustered around the 1/2 length size and write them to disk. That's a lot of primes but we have plenty of time, plenty of disk space, and a rather smaller search space based on our assumption.

Next you create "rainbow tables" by multiplying the resulting primes, keeping only a small portion of the result such as the first 16 bits, and the two primes used to create the key.

Now, given a key to break, you index it by using the first 16 bits as a hash key, finding a "bucket" of prime products that result in the same 16 bits.

For each entry in the bucket the question is "if I recreate the product of the primes, does it match the key?"

It is "brute force" on a large scale but I'd bet that certain agencies can create these rainbow tables and that with sufficient effort such tables could "break" any crypto key you're likely to generate using commodity hardware and software.

Just a thought...

I've been listening to "This Week in Virology" (aka TWIV) (https://www.microbe.tv/twiv/) for more than a year, about 100+ podcasts so far.

This is a podcast about viruses. All of the people are fully qualified active or retired virologists. They have interviewed dozens of leading virus researchers and other viral-connected individuals (including Fauci).

In their professional opinion there is no possible way this virus was created in a lab.

Is it ironic that I opened this in a tab?

I'd like a browser function that says "open a text file and save all the URLs"

If you're running Linux you probably want to do development work (just a guess).

My Linux boxes have uptimes of several years which is perfectly normal.

WSL has uptimes of several days. Microsoft will reboot your machine to install an update and you'll lose all of your development state. WSL is a pretty toy.

Given the choice (and I do have that choice) I only use WSL for trivial tasks like running a curl command.

Your karma may vary.

One more rule. Proofread your document.

question marks go inside our outside

should be:

uestion marks go inside or outside

Did something happen to Robert?

Lisp?

In 50 years of programming I found:

(a) time estimate are dangerous. In one case the leader of our team estimated 5 people for 5 months. The company wrote a fixed-cost contract. After 10 people for 18 months the company folded.

(b) time estimates are meaningless. All of the software I worked on was new. There was no "prior art" to ground the estimate. Projects were almost always "late", mostly due to changing requirements.

(c) time estimates assume a known future. Who expected the pandemic? (Or the Spanish Inquisition?). How good is your estimate when the 6 people you could "hire" are all rejects from other projects because they can't program?

(d) time estimates assume a known good tool set. CorelDraw won't run on your old Mac but the company won't pay for new hardware. Microsoft pushed out a "destruction tuesday" update and now your machine won't boot. Somebody "upgraded" the library software and now your code won't compile. And don't get me started about chasing a compiler bug (I've fought 5), each costing an unplanned week. Or hardware bugs (3 times), that basically stopped the project until they were fixed.

(e) time estimates will cost you time and money. Suddenly everything become a crisis. Cancel that vacation. Work nights. Work weekends. Nobody gets a raise if this is late.

(f) time estimates WILL be used against you. Managers write down the "estimate", stick it in a drawer, and when "blame time" comes you can be certain to be "to blame" for a bad estimate.

I know you think I'm wrong. You "just know" my "lived experience" is nonsense.

You can't estimate software. Get over it.

Read "The Mythical Man Month".

That's interesting. I'll look at it. Thanks.

I can highly recomment Robert Paz's channel

https://www.youtube.com/channel/UC7uJBXcRdGlDlKIyr6ZbjBw

I have a "prototype" but it is still in the truly hacky stage. When I have a decent "first draft" I'll post a github link.

I want to try it on a range of microprocessors. Some of them, like the Arduino, have strange memory layouts. I just figured out how to write assembler code for the Arduino.

They should have directed to a Rick Roll video :-)

The field of software is exploding in many directions (e.g. machine learning, quantum programming, program proofs, dependent types, category theory, etc).

At the hardware level it is also exploding. There are a dozen new computer architectures and instruction sets. It is now possible to design your own cpu (yes, I am) and build it in an FPGA at the cost of a few dollars. That forces you to learn VERILOG and processor design. It also forces you to learn electronics in order to breadboard your ideas.

The field is also converging. Intel now has a cpu that also has an fpga. (This is only available to the FAANG players it seems, which is a source of frustration for me. Why, Intel, Why?). Imaging being able to build your own instructions "on the fly". I want to implement Gustafson's UNUM arithmetic (see "The End of Error" https://www.amazon.com/End-Error-Computing-Chapman-Computati...)

It's not clear what the long-term shakeout will be but it is fun to try to learn what the leading edge is doing.

Like the Red Queen from Alice in Wonderland said

'Now, here, you see, it takes all the running you can do, to keep in the same place. If you want to get somewhere else, you must run at least twice as fast as that!'

I'm doing all the running I can to ride the leading edge.

What could be more fun?

Rich Hickey "thinks in lisp". For example, he talks about his "maps" data structure (aka association lists). See https://www.youtube.com/watch?v=aSEQfqNYNAc

Since data and programs are the same thing in lisp you can fluidly shift from one to the other, like I did with "knowledge" vs "rules". They both have the same representation (defstructs) but they are also code and have execution semantics. Clojure allows you to do this with map objects.

The fact that you can use the whole language on everything at any time and that everything at any time is also "the language" is how you "think in lisp". Nobody thinks of Python programs as "data" or data as Python programs.

Watch anything Rich Hickey talks about. He really "gets it".

Language limits what you can think. For example, you clearly feel that an interned symbol is essential to "lisp". But if I think about Lisp as lambda calculus notation there is no notion of "interned", yet it is still "lisp".

When I transliterate to Python I am not, by definition, worried about performance. Python has horrible performance.

Ah, the "Pythonic way" of doing things! Like the "Steve Jobs" way of doing things, aka the one-finger interface. "Steve Jobs thinking" would bring us a "self-driving car" that we "drove" by tracing a finger along a moving map, clicking on stop signs to stop. We'd be singing about how marvelous it is... it "automatically" blinks the turn signal when we trace a finger along a left turn! Python is the "Steve Jobs" of languages and thought: so easy! so intuitive! so limited!

You ask "Are you sure your language of thought is really Lisp?". I'm also a mathematician. You're asking me if I think about math in terms of multiplication. I do, but not the way you expect. MY multiply can be non-commutative if I'm working in matrix algebra. It can be a map function in category theory. It can be limited to finite fields or expanded to octonions. I'm still thinking of "multiply"; I'm just not limited to numbers.

Similarly, when I'm thinking about a problem my "lisp thinking" isn't limited to symbols. I worked on a Human-Robot cooperative task to change a car tire. I needed a knowledge base...lisp (aka Scone). I needed rules... lisp (aka ops5). I needed human language... lisp (my own code). I needed it all to work together so that rules could be represented as knowledge and knowledge could be expressed as rules (all were defstructs). When thinking about the problem I could write "lisp pseudocode" and then simply execute it. If I needed "multiply" to be non-commutative in some section of code I knew I could make it work trivially. Indeed I didn't even have to think about it.

Thinking in Lisp has nothing to do with interned symbols, just as thinking in math has nothing to do with numbers.

Thinking in Python is like doing math on a calculator. Everything is "Pythonic", but just like your "calculator" in math, limited to numbers.

I think the reason people "don't get lisp" until "they get lisp!" (aka the epiphany event) is that they stop thinking in other languages and begin to think in lisp. A whole new world opens.

Assuming you're not trying to be sarcastic...

As a "language of thought" it is often the case that I will write my solution in Lisp and then "hand translate" it to the target language. This has two effects.

First, assume I'm "translating" to Python, for example. The Lisp "Gedanken" keeps me from depending on strange local language behavior. For example, I won't have to catch missing dictionary entries. But if I happen to want a local language behavior I can just make a macro.

Second, the Lisp "Gedanken" allows the ability to "factor" solutions since Lisp tends to "encourage" functions. For example, I'm working on a design for a dependently-typed language that allows proofs of the resulting programs. Lisp allows me to create a domain-specific language easily. Gedanken experiments led me to factor the category, domain, and representation for the specification, implementation, and proof languages. I know from experience that whatever domain-specific language constructs I dream up, they can all be implemented as macros and compiled efficiently.

When "thinking in Python", you'll find yourself restricted by implementation issues or searching for some library and then shaping your problem to fit the library. When "thinking in Java", you'll find yourself trying to force your solution into "objects". When "thinking in C++", you'll find that (a) you have to choose WHICH C++ (there are so many) and (b) by the time you implement something C++ will have changed.

I can still run Lisp code I wrote in 1980.

Assuming you ARE being sarcastic... there's Greenspun Tenth Rule:

Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp

The fact that you've immediately gone to "interned symbols" means you aren't used to using your language for thinking. These things don't arise in Lisp Gedanken.

Cogito, ergo Lisp

On the other hand you could hand-punch paper tape with a little plastic thing, one hole at a time. That way you could "patch" a paper tape. I used to have tapes with patches on patches (overwrite memory with each patch). Eventually I had to "memory dump" new tape that "merged all the patches" to get a new "master tape"

good times.