samwilliams

Ha! I literally built that last week: https://molecule.arweave.net/#/bugcraft

Infrastructure is an FPS now.

Helpful article providing a less dense overview:

https://www.sciencealert.com/hoyle-wickramasinghe-thesis-com...

Put aside for a moment the name for the 'scheme' and consider the mechanism design differences between USD and Bitcoin:

- USD is needed in order to pay taxes on the US, but can be printed arbitrarily by a centralized mint.

- Bitcoin has no fundamental demand driver, but does have a truly capped supply.

Why is it so obvious that USD is a preferable scheme?

I think the reference to retirement funds is in relation to the fact many of them are under collateralized. They need to take new investor's money to pay out old investors.

Some more background here:

https://www.google.com/amp/s/www.wsj.com/amp/articles/an-ohi...

The situation is pretty extreme. To be honest, these really _do_ look like Ponzi schemes.

That first link is an incredible rabbit hole. Thank you for sharing.

Whistleblower that spoke to WSJ.

Hey dweller!

That isn't the mechanism. What happens instead is akin to an endowment for payment of storage. An outline is found here:

https://www.arweave.org/faqs.html#what-is-a-storage-endowmen...

And the paper has the full details:

https://www.arweave.org/files/arweave-yellowpaper.pdf

Thanks for the comment @blacksqr!

This calculator is outdated -- the current price of storage oscillates around $0.01/MB. The maximum single chunk size is also 10MB now, and you can send as many chunks as you like.

A community member built a blogging platform on our permanent, decentralised web (Arweave) today. You might want to check it out:

https://arweave.net/egqLRAbESk4BvrPZGwNM-koJZZU3_xYRb_G9-CYC...

Full disclosure: I started the Arweave project.

Sam

I think the HN crowd has always been interested in this sort of stuff? It certainly has since I started reading it (~7 years ago). One of the things that I like about HN is that we are not completely inward looking.

From the guidelines:

> On-Topic: Anything that good hackers would find interesting. That includes more than hacking and startups. If you had to reduce it to a sentence, the answer might be: anything that gratifies one's intellectual curiosity.

> Off-Topic: Most stories about politics, or crime, or sports, unless they're evidence of some interesting new phenomenon. Videos of pratfalls or disasters, or cute animal pictures. If they'd cover it on TV news, it's probably off-topic.

You could certainly say that a BBC group being forced to sign a confession for attempting to conduct an interview 'gratifies one's intellectual curiosity' about the world, but it could certainly fall under 'Most stories about politics, or crime', too.

Either way, as you point out, once a post has over 100 points you probably have your answer!

Hi,

Thanks for your thoughts. As I have stated elsewhere, the code handles all of the cases I needed it to handle, due to the stability of the input file format (which was emitted from another program). I don't see that this should be too hard to believe.

I also said in my second edit, on the top line, 'Not so trivial after all!'. If I was putting on some kind of act, wouldn't that have been dropping it? Further, I noted in my first edit, before I had received any replies, that I 'know this version won't support escaped separator/newline characters', so I am not sure what you were trying to add with your example?

I think that my central point (and I totally accept that I didn't express this well) is that depending on the specifications of your program, the required CSV parser /can be/ very short. When one compares this to other data exchange formats, for example JSON, it is clear that the barrier to /entry/ is much lower. The shortest JSON parser I could find with a cursory look was 200 lines of C.

I totally appreciate that to write a CSV parser that works for all cases would be extremely longwinded. It has been interesting to hear other people's experiences and opinions about that. But the fact remains true that /in some cases/, depending on the requirements of the program, the parser can be very short.

> We all recognize the classic developer I-could-build-that-in-a-weekend hubris when we see it. :)

It is funny you should say this. I needed the CSV parser because I thought it would be fun and interesting to see if I could build an anti-malware tool in a week (I am taking a malware detection class at the moment, I wanted it done before the next lecture). I did not expect I would be able to have anything good working in that time, but by the early hours of the next morning I had a perfectly functional anti-malware tool. It can use ClamAV signatures (so it can detect everything(?) that ClamAV can), runs in parallel, has a nice text console with DSL, and is fast enough (processing 210k small files in ~5 minutes, checking against ~60k sigs). It is about 650 lines of Erlang (including comments). I am saying this not to boast(!), but to make the point that I greatly underestimated how productive I could be, beat my expectations by many fold, then people comment about my hubris online the next day. It is funny how life goes!

Thanks,

Sam

I submitted that edit before the post had any replies.

Also, I did try to make clear that the given code was created 'for a specific use case in which I knew' that the format of the input files was tightly defined.

This is interesting, and as the other commenters have pointed out, creating a parser for /all/ variations of CSV can be very tricky.

Ah right, yes, I can imagine that would be extremely messy!

That is very interesting, thanks! I hadn't thought about Unicode or tolerating human error. Although the times I have worked with it have been when it is a transport medium between two computer programs.

Do you mean Excel to CSV? Or a CSV importer?

I totally agree about Excel importing, but CSV is trivial, no? Here is an Erlang version I happened to write yesterday:

  lists:map(
    fun(Row) -> string:tokens(Row, [SepChar]) end,
    string:tokens(InputStr, "\n")
  ).

EDIT: I know this version won't support escaped separator/newline characters, but I made it for a specific use case in which I knew that would not occur. Adding that functionality would make it a little messier, but still not too bad.

EDIT2: Thanks for the interesting comments! Not so trivial after all!

Perhaps a more accurate version of what I was attempting to say above is that 'it is often (not always) easy to build a CSV parser to interact with one specific program'. The four line version above works perfectly for reading the type of files I designed it for. If you want to work with human created, or more complex variants of CSV, all bets are off.

Ah, thanks. That makes sense.

This is very neat!

I created an Erlang script that allows you to send messages by morse code to the keyboard like this:

  ./remote_morse "HI,IAMSAM."

(Spaces don't appear to be used in morse code?)

The messages won't be differentiable while the site is under HN-level traffic, but in a few months, you should be able to send arbitrary messages to @lelandbatey using this.

The code is available here: https://gist.github.com/samcamwilliams/19339ea2d8431f27728ec...

Do you mean with the 'little book of OS dev'? Or one of the other resources?

In general, my experience has been that OS dev is a topic that is best approached through the study of a variety of different documents, simultaneously. For example, you would do well to read both the originally posted 'little book...', as well as the University of Birmingham text. Then it might be a good idea to look at the OSdev wiki pages for the specific tasks that you want to work on.

> but it seems dead and no one has taken the time to fix such issues

Unfortunately, there seem to be few /completed/, and high-quality texts available. It is certainly a shame that there is not a modern, high-quality book about OS development (that I know of), but the motivated student can certainly find the needed information. Good luck and have fun!

Thanks! At the moment, the best source of information is the talk I gave at the Erlang User Conference 2016 [0]. Four papers and a thesis are in the pipeline for next year, though! I will update the site once PDFs of those are available.

[0] https://www.youtube.com/watch?v=9XqHiumZ02E

As someone that has just spent the last 27 months building an OS from scratch in a University research environment (an OS that can survive catastrophic hardware and software failure [0]), I am very impressed with the quality of this document. I only wish I had found it previously!

OS dev can be great fun and gives you a level of understanding about how computers actually work that is hard to gain from other sources. I have frequently found myself using the knowledge I gained from building the OS when working on other projects. It has been particularly useful when it comes to understanding performance issues. I would highly recommend it to anyone that is even remotely interested.

Other superb resources to help you get started include the OSdev wiki[1], along with this document[2] from the University of Birmingham, UK.

[0] http://www.hydros-project.org

[1] http://wiki.osdev.org/

[2] https://www.cs.bham.ac.uk/~exr/lectures/opsys/10_11/lectures...

Key quote: "The outcomes of algorithms are regulated – the companies which use them have to meet employment law and competition law. The question is, how do we make that regulation effective when we can’t see the algorithm?”, UK Shadow Minister for Industrial Strategy.

Labour are currently trailing the ruling Conservative party by 7 points in the polls, with no election due until 2020 (although a snap election is certainly possible).

> thought "cyber" wend out in the 90's

A year ago someone in my research group claimed that they were 'getting into cyber'. I looked around the room and almost every other member of the group looked confused and a little concerned.

Apparently 'cyber' has become a byword for 'cyber security'. I hope that this does not last.