The BASIC Issue with Retro Computers - <AUTHOR> http://hackaday.com/2016/11/18/the-basic-issue-with-retro-computers/ <comment> david-given If you're interested in BASIC, there's an open source BBC Basic V interpreter:

[https://sourceforge.net/projects/brandy/](https://sourceforge.net/projects/brandy/)

(Also in Debian.)

BBC Basic is one of the best BASICs ever, featuring things like named procedures with local variables, structured programming, etc. Basic V, which Brandy simulates, is effectively Comal.

But you don't have to use any of that stuff if you don't want to, and all the old favourites like GOTO, GOSUB, ON GOSUB etc still exist. (Along with a handy RENUMBER command for when you run out of space between lines 140 and 150.)

I recently found an ancient program I wrote as a teenager in BBC Basic II --- I'd submitted it to a computer magazine to be printed in an issue (and then they rejected it). If you want to know what BBC Basic II looks like, here's an example.

[http://cowlark.com/2015-02-03-bbc-micro](http://cowlark.com/2015-02-03-bbc- micro)

 _Edit:_ cut-n-paste tyop.

<comment><USER3> _" I agree BBC BASIC is excellent, particularly in having structured programming support."_

Found this in the article comments. What happened to the BBC BASIC language? Is it still available, in source?

<comment> david-given Well... the original BBC Basic was originally hand-written in 6502 assembly for the BBC Micro; it's a 16kB application ROM. Later versions were rewritten for the 65C102. The extra opcodes available freed up some space and they added a few more features, and made it even faster (and BBC Basic was _already_ one of the fastest 8-bit Basics around). I don't believe that any of the 6502-era Acorn sources were ever released, which is a shame, as Acorn's MOS was one of the best 8-bit operating systems around.

Basic V was a complete rewrite for the ARM. In hand-tooled ARM machine code, also by Sophie Wilson. The source for this _is_ available from the CVS archive here: [https://www.riscosopen.org/content/downloads/cvs- access](https://www.riscosopen.org/content/downloads/cvs-access) But trust me, it won't help. I've debugged my way through it. It's very... hand written.

Oh, yes: there are _also_ ports of BBC Basic IVish to the 8086 and the Z80 by R.T. Russell: [http://www.bbcbasic.co.uk/bbcbasic/bbcbasic.html](http://www.bbcbasic.co.uk/bbcbasic/bbcbasic.html) He wasn't associated with Acorn, as far as I know. The 8086 version (for Windows and DOS) is commercial, but the Z80 version (for a variety of CP/M machines) is a free download. Not open source, unfortunately. His version even includes 80186 or Z80 inline assemblers, depending on the version. His Z80 port was licensed for a variety of machines --- Amstrad made a range of Z80 notebooks with his Basic in ROM. I've used all his versions, and they're superb.

<comment><USER3> _" The source for this is available from the CVS archive here: ... But trust me, it won't help. I've debugged my way through it. It's very... hand written."_

First computer ZX80, so I missed the BBCM.

Thx @David, the reason I asked was I was interested to see ^how^ it was written, but probably more to the point, what made it good? Sounds like speed was a loved feature. Was there ever a API or documentation made public?

Reason: want to hack a language together a BASIC-like language (are of use) for graphics.

<comment> david-given Well, there's an annotated disassembly here:

[http://acorn.huininga.nl/pub/docs/sourcecode/Acorn/BASIC%202...](http://acorn.huininga.nl/pub/docs/sourcecode/Acorn/BASIC%202/BASIC2.asm)

AFAIK there wasn't anything particular magical about it --- it was just written well, with great care. Programs were stored in tokenised form, where each keyword was reduced to a byte, and line numbers in things like GOTO statements were stored preparsed, but execution happened directly from the tokenised form. Named procedures were faster than GOTOs because the interpreter would cache the address of the line where they were defined, while GOTOs would have to search for the line; variables were stored in a hash table; there were two stacks, one for GOSUBs and one for PROCs (the GOSUB stack was much smaller!); there was a superb 5-byte floating point library...

It's also worth mentioning that Acorn's MOS was in a different ROM, so it didn't have to share space with Basic. The two communicated via a system call interface. I've seen people run BBC Basic on entirely different 6502 machines by reimplementing the system call interface.

I would _not_ recommend writing this style of Basic if you want a simple language these days. Basics are a nightmare of ad-hoc parsing with too many edge cases. Better to write a modern byte-compiled language with a byte interpreter --- you'll end up with something much cleaner and easier to understand. We're not all Sophie Wilson.

<comment><USER3> _" I would not recommend writing this style of Basic if you want a simple language these days. Basics are a nightmare of ad-hoc parsing with too many edge cases. Better to write a modern byte-compiled language with a byte interpreter --- you'll end up with something much cleaner and easier to understand."_

thankyou for these suggestions.

 _" We're not all Sophie Wilson."_

agree, very talented individual.

</comment></comment></comment></comment></comment></comment><comment><USER4> Another fascinating concept of old computers is about 10 years before FOSS and about 30 years before github we used to buy strange telephone book sized tomes with titles like "Journey to the Center of the ROM" and they were commented disassemblies of the rom that shipped with the BASIC from the linked article, for example. On the theory that you'd learn yourself a little something by studying how an "old timer" with 2 or even 3 years of Z80 assembly experience wrote a basic interpreter, because you were a noob with like 6 months experience. And they had similar books for other system software like various disk operating systems (not the IBM product from many years in the future)

Coolest thing about those books is they're up on archive.org just like the article's BASIC books.

Now... one thing to realize is bits cost money back then so self modifying code was "clever" not insane. And an old timer having maybe two whole years of experience meant that the code probably looks extremely amateurish today. But, it worked, and back then the only way you got to patch bugs was to sign a contract for new masked roms and then physically install them, in other words it didn't happen, so its a good thing we only had 4K eproms and so on because that's only 4K possible things to be a bug, um, sorta. Kids these days don't realize in the old days software was like un-upgradable firmware today. Some dude screws up the key debounce routine in the rom of your TRS-80 model I, well you better like it that way, or like patching manually after very reboot...

Something I was just thinking about today is noobs today must have it extremely rough being dumped into advanced data structures and RTOS and interrupts and multithreaded programming and GUI interfaces right at the start. In the old days life was easy because stuff you wouldn't understand as a noob didn't exist, or at least you could mostly ignore it. Nobody got confused about MALLOC memory on a TRS80 until they knew what it meant and why they wanted it because it was a model 3000 running linux 1.0, but in 1981 the whole topic couldn't confuse noobs because it wasn't there.

<comment><USER5> Nowadays, you can still ignore: while you're so low down on the stack that you don't have to worry about that stuff, new newbs don't have to worry about that stuff because they're too high up the stack. Many new newbs learn javascript, so not only are they upstack, they still have to deal with the "joy" of re- writing the display by hand every frame.

And I should know, because I was one (although I learned python, and never got into the graphics stuff).

</comment></comment><comment><USER6> If you're interested in old computer programming, Usborne recently released downloadable PDFs of their childrens' computing books:

[https://www.theguardian.com/technology/2016/feb/10/programmi...](https://www.theguardian.com/technology/2016/feb/10/programming- usborne-1980s-coding-books)

In addition, I wrote an article for Commodore Disk User on interrupt requests some 25 years ago and was pleasantly surprised to see that the magazines are available on the Internet Archive:

[http://alblue.bandlem.com/2012/04/first-published- article.ht...](http://alblue.bandlem.com/2012/04/first-published-article.html)

[http://archive.org/details/commodore- diskuser](http://archive.org/details/commodore-diskuser)

<comment><USER7> I grew up with these books! And 80s computer magazines too (UK Spectrum mags in my case though, but also C&VG). Thanks for the links.

I loved to get Usborne books as presents or go to the library every week to see if they had any new ones. Still have a few, including one which I couldn't see on the website. Maybe I'll check and email them about it.

I was at the computer museum in Swindon (UK) last week. It's a small museum but they have among other things a couple of Sinclair machines and a C64 set up for people to play with (type in BASIC or load games from tape/disk/cartridge). I attempted to type in a simple program to draw a coloured pattern onscreen from one of the books provided, but I'd forgotten how to type some of the Spectrum's more obscure shift-keyword combinations and after 30 years of progressively nicer IDEs the 48k BASIC editing interface was quite frustrating. Still, good for nostalgia.

Would recommend to micro nostalgists if you're in the area, although it's possible to look at everything they've got within an hour so probably not worth driving much more than that for.

(I suppose I could donate my Usborne books and magazines - if I could bear to part with them...)

</comment></comment><comment><USER8> I keep thinking of ways to get my kids involved with computers in a more intellectual way. The oldest likes the gamified programming with blocks but has no real desire to explore further. He has been interacting with iPod touches or iPads since before he could walk. I think it was a mistake in retrospect.

Just the eagerness to get your hands on a computer is hard to describe today. Studying the ads in magazines. Hanging around electronic stores. Riding bikes miles to friends who were more fortunate. Even today looking through an old Byte magazines at obsolete hardware almost has me salivating.

I know that today there has never been more capable hardware, more available, more affordable and with the level of help and documentation that we have on the Internet. But it is still hard to let go of the 80s. It was a time when kids with no Internet or peers to help would spontaneously disassemble ROMS and hand code asm. I had two television channels which played no more than an hour of content a day of any interest and the only console game we had was a Pong made from a kit. Although the primitive nature of old computers helped their learnability the lack of distractions was also helpful.

<comment><USER5> Get him into Zachtronics games: start with Spacechem. Then give him TIS-100. Then give him a micro (of some sort).

Hope that helps.

<comment><USER9> Try Techcompliant. Where you can use an 8 bit computer to control a spaceship or a whole space station.

<comment><USER5> ...hang on a minute. AFAICT, that's another 0x10c spinoff.

If you don't know, 0x10c is a (semi-famously) aborted game project by Notch, which was was known for its 8-bit DCPU computer, which would control your spaceship. Techcompliant seems to be one of several continuations of the concept.

I'm pretty sure Project Trillek is the most active continuation project, but this also seems worth looking at.

Until they're done, though, you can pay TIS-100, or backdate your mincraft to 1.2.5 and install RedPower2. Or you can wait for RedPower3, the game of _that_ mod, which goes in a similar direction.

<comment><USER5> Actually, scratch that. Trillek is less active. Hopefully, Techcompliant is good. I wouldn't know, because there's no way to actually get the game.

</comment></comment></comment></comment></comment><comment><USER10> I was less than 10 years old in the sea house we rented in August here in Sicily, 1986 or alike. ZX Spectrum connected to the TV, and me working to make a point moving with the arrows on the screen, a problem that was for me unsolvable. Then, suddenly, I realized that I could updated a var in terms of itself: X = X + 1. A whole new world opened in front of my eyes.

<comment><USER11> Back then computers came with real manuals and tutorials.

My family bought a 48k ZX Spectrum for Christmas one year, and the tape-deck didn't work. So no games for my sisters and I. Instead I started programming via the orange programming guide/documentation. My sisters lost interest until we could get a working cassette player a few days later.

From BASIC to z80 machine code - again via the documentation - was a great start.

<comment><USER10> Yeah... there was no internet, and in my case, no local group of users, so either the manual or it was impossible to use it :-)

</comment></comment></comment><comment><USER5> I grew up in the 2000s: No assembly hacking for me. And even if you learn assembly, you're essentially just doing a C compiler's job.

...Which is why I'm building a Z80 machine. It won't be complicated (no monitor, just a DB9 cable connected to a Z19 (and yes, I have a Z19: my father's actually)), but it will be programmable from the ground up. It will be something that I can learn from.

But no way am I implementing BASIC. Sorry, it's complicated and not actually all that good a language. So I'm implementing FORTH. Simpler, and the stack might be a pain, but I'll learn something from that, too.

<comment><USER12> I agree with you. I so wish that the microcomputer culture was based on Forth rather than BASIC. BASIC is a terrible language, but people do like it more than Forth for some weird reason.

(I started on ZX Spectrum in late 80s. If it had Forth, it could fit twice as much stuff into its ROM than it actually did.)

But, we live in a world where Javascript is having Haskell for a dinner. So I am not really sure why I am surprised.

(On the other hand, at least Python is a decent language, even though Lisp should have won in that particular space.)

<comment><USER13> In case you haven't seen it, Factor is a modern FORTH-like language:

[http://factorcode.org/](http://factorcode.org/)

Funnily enough the most I've ever played with FORTH was inside of Minecraft on an in-world computer:

[http://technicpack.wikia.com/wiki/Forth_language](http://technicpack.wikia.com/wiki/Forth_language)

<comment><USER12> I am aware of Factor, although I believe that conceptually, FORTH can only work in small systems. In a larger system, you can afford yourself something like Haskell (or at least Lisp) and the extensibility and proximity to hardware of FORTH will diminish in value, while the disadvantages will remain. In other words, with a bigger machine, you can go with more abstract language (distancing from hardware but keeping the extensibility), because the compiler/interpreter can be made more powerful.

I also played with FORTH mostly in Minecraft Redpower 2 (but before that I also read Jones Forth, which is excellent), unfortunately, to prove my original point, people didn't like it and longed for BASIC.

<comment><USER5> Ah, RP2. On of the finest mods that ever came out of the fantastic modding scene around Minecraft. It was one of the four foundational mods in the scene: BuildCraft, IndustrialCraft (and later IC2), Better Than Wolves, and RedPower2.

Sadly, RP2 is dead, and with it the RP2 computer model, the likes of which will likely never be seen again (for those not in the know: most mincraft mods adding computers of some sort essentially allow scripting in some HLL, and maybe a primitive DOS-style prompt, akin to ComputerCraft. Not so in RP2. RP2 computers were actually full emulated 6502s, with a FORTH monitor built in (although you could, of course, write your own). This should give you an idea of what made RP2 so special). Except not quite, because Eloraam is now working on RP3, which will actually be its own game, because she got sick of putting up with MC's limitations. Knowing Eloraam, it will be done by 2030.

<comment><USER14> Related to RedPower: OpenComputers. While it does come with Lua as the default OS / platform but it has support for arbritary computing architectures - <USER2> real and fake. I'm not sure if any has matured to the point of RP2 though (I know someome at least _attempted_ a 6502 architecture at: [https://github.com/gamax92/ocsymon](https://github.com/gamax92/ocsymon))

</comment></comment></comment></comment></comment></comment><comment><USER15> I can't believe how very much I can relate to the first 5 paragraphs of this post. It hits home at very core of what (unknowingly at the time) formed the basis of my career.

I started on the VIC-20 (for which I traded in my old, but working Fairchild Channel F, Doh!) and then moved up to a C-64. One of the first games I had came on cassette tape, was written in basic and at a certain point... you'd hit a syntax error... fixing that bug was my introduction into programming in early Junior High School. And to the point of those opening paragraphs, I remember the Programmer's Reference Guide for the C64 included schematics for the computer.

The limited nature of the BASICs that came in ROM also very much forced me to learn fundamentals of computing that I appreciate to this day. If you wanted to draw circle on the screen you had to perform bitwise operations with the screen memory using "PEEK" and "POKE"; there were no fancy "CIRCLE" or "DRAW" commands. At the time, my friends had computers that could do those things, but the extra effort with my computer had pedagogical value that continues to pay dividends today.

<comment><USER16> > One of the first games I had came on cassette tape, was written in basic and > at a certain point...fixing that bug was my introduction into programming in > early Junior High School.

In a similar vein, the first games for my Apple II were in Basic on tape, and I figured out how to cheat at them by changing parameters in the code.

</comment></comment><comment><USER17> If I could start learning BASIC on a ZX81 at the age of 7, I'm pretty sure anyone can. This is the era that got me into computers, and hopefully with the Pi and similar programmable devices available that are aimed at educating kids, that time will come again.

There's even a new version of the ZX Spectrum on it's way. [http://www.specnext.com/](http://www.specnext.com/)

<comment><USER5> ...Or, you can just build a ZX80/ZX81: [http://searle.hostei.com/grant/zx80/zx80.html](http://searle.hostei.com/grant/zx80/zx80.html)

<comment><USER17> Our ZX81 came in a kit, so in essence I already did (with a lot of help).

<comment><USER5> Oh. Heh.

I guess things really don't change.

Except now you have to buy it piecemeal.

</comment></comment></comment></comment><comment><USER18> Being dumped straight into a BASIC interpreter after boot was huge to get kids interested in computers. ZX Spectrum was that way, and it is the reason I am a computer programmer today.

It wasn't much code but you had to write a one-liner at least:

       LOAD ""

Then you figure, "What other stuff is there?". Oh you could modify memory to get infinite lives in games and such so you find out about PEEK and POKE. You could go as advanced as you wanted. Wrote my own assembly interpreter. There was a C compiler, a Pascal one. If it crashed, had load everything from tape again.

I remember writing and selling my first program when I was 13. My friend's dad ran an semi-legal broadcasting company showing dubbed American movies to a few apartment blocks in the area, so I wrote a program to display the schedule and movie summaries before movies started. As payment I took a cassette tape with music on it, probably something like 2Unlimited or similar ridiculous thing. No regrets though...

<comment><USER11> 30 years later I still remember: POKE 23659,0

I got my start on the ZX Spectrum, as you say hacking games for infinite lives. First of all cracking the tape-based protection system (bleeplock, speedlock, softlock, movieload etc), then the games themselves. I guess I was lucky in that a lot of these protection systems were evolving as I was working on them. Jumping in to the more advanced system without having experience of naive protections that were available even six months beforehand would have been impossible for me.

<comment><USER18> The one I remember besides LOAD "" is

       RANDOMIZE USR 0

Also come to think of it, my ZX Spectrum (a Soviet clone of it really) was probably the reason I learned English. All the games and programs were in English, wanted to devour all that info so I learned a new language as a side- effect.

</comment></comment></comment><comment><USER19> If there's anything that can make you realize how vast the computing resources we have at our disposal are, it's the fact that 1970's and 80's era 8-bit computers, running BASIC programs, even though this was hundreds of times slower than running machine-code programs, were still considered very useful tools.

Outside of high-speed games, the principal complaints that people had back in the day with running BASIC programs had very little to do with the execution speed and more to do with the memory, tooling and display limitations of the platforms they were working with.

It's a great miracle that now, in the modern age, we've managed to build up such intense piles of abstraction that it's not unusual to see a machine capable of billions of operations a second perform as fast as a machine capable of millions of operations a second that was also running BASIC code.

</comment><comment><USER20> The problem was that BASIC was your first step in this progression:

1) Program in BASIC--realize that you can't do everything that other programs can do

2) Program in BASIC with Peek/Poke and USR()--realize that you _still_ can't do everything that other programs can do

3) Program in Assembly--realize that you can now do everything other programs can do--and programming is _painful_.

I was lucky to be on a TRS-80 Color Computer and had William Barden producing excellent books and articles for it.

<comment><USER4> I distinctly remember this book after my Z80 adventures:

[https://archive.org/details/Color_Computer_Assembly_Language...](https://archive.org/details/Color_Computer_Assembly_Language_Programming_1983_William_Barden_Jr)

I also remember "leveling up" going from edtasm cartridge pack to Microware OS-9 and being pretty well blown away, like today going from edlin or GNU-nano to suddenly emacs. Whoa...

<comment><USER21> I am forever grateful that I happened to start with the Color Computer: the 6809 was the best introduction to assembly available at the time.

So far, I haven't done any Z80 or 6502 programming.

And as much as I love the 6809, I'm super happy to ARM machines to play with now.

</comment></comment></comment><comment><USER22> While we're sharing BASIC stories, middle school me was like "wait, hmm, I can take a 'long' number, take the cosine of it, and get a 'shorter' number. COMPRESSION!" It was then that i learned about how a computer stores floats, and essentially a bit about entropy. I then started to really understand floats when I tried to use cosine as an encryption function and then all the lost precision became obvious.

</comment><comment><USER23> As a kid I always wondered why my Amstrad computer turned all keywords in a listing to Uppercase...

... years later I figured out they were coding internally every basic keyword into a lookup table, thus saving your precious 64kb of RAM. The Spectrum did the same, but they didn't have to parse the strings: you had to type the correct key combination to actually write the sentence (does anyone remember spectrum k,l,c, and e cursor modes?)

<comment><USER24> And speeding the program up, too: because each line had been tokenised on input, the interpreter's work at runtime was much less.

I miss my Amstrad.

</comment></comment><comment><USER25> "In no other era could a title like "Machine Code For Beginners" have been a children's book."

This is so, so true. I cannot even imagine such a book for kids or even teenagers now. Something was lost when computers became powerful and boring.

<comment><USER5> ...Really? I'm a teenager now. I'm actually learning z80 assembler. And GBZ80, which is actually closer to 8080.

I don't know if I'll ever manage it, but that's not because it's too hard, it's because I famously never finish projects.

<comment><AUTHOR> Modern x86 assembly would probably fill a dozen thousand-page tomes...

<comment><USER9> Classic x86 (16 bit) not was hard to understand. The most problematic is the segmentation system. But beyond of it, it's very straightforward.

I got some knowledge from one of the Norton's book.

<comment><USER5> Well, yeah. Classic x86 was a well known instruction set. Not so for modern x86.

Segmentation still sucks, though.

</comment></comment></comment></comment></comment><comment><USER26> BASIC was an awesome language to get started with. It's simple to learn and gives a quick feedback loop that you're making progress. People obsess about teaching beginners good principles from the start but forget if it's too unforgiving to begin with you'll drive a lot of people away.

<comment><USER5> Yeah. Dijkstra got that one wrong.

</comment></comment><comment><USER27> There are few things in our industry better than seeing someone pick up an old 8-bit machine and doing something amazing and cool with it, using modern processes and even tools. If you think you're an elite hacker but you've never written a scrap of 6502 code, you've got some distance to the end of the race yet, young 'un. Get out there and get yourself a real computer.

And remember this, always: old computers never die. Their users do!

<comment><USER5> >Get out there and get yourself a real computer.

Ironically, this is what hackers from the world of Big Iron (MIT LCS, MIT AI, and MIT MDL (much of which would later become Infocom's Imps and hackers), most famously) said to micro users at the time.

What an irony, that HN is full of kids who grew up on Micros, and yet the culture is a direct descendant of the LISP and UNIX lab cultures of old, whose hatred of micros was legendary.

<comment><USER27> All the Big Iron hackers I used to know (and got my grommet wings rubbed by) are dead now. :(

<comment><USER5> ...That's sad.

I really don't know what else to say.

<comment><USER27> Well, their computers are probably still out there, humming away. At least, in my mind they are.

</comment></comment></comment></comment></comment><comment><USER28> BASIC was kind of nice, I liked to program simple adventure games on it. Too bad I never really figured out arrays and DATA statements, that would have helped immensely with getting more complex things done.

<comment><USER29> Indeed, I can remember trying to make some kind of space game that declared data like this:

      LET PLANET1$ = "Earth"
      LET PLANET2$ = "Mars"
      LET PLANET3$ = "Venus"
      ...
      LET PLANET45$ = "Sirius"

And rendered its amazing 16-color EGA screens like this:

      PSET 0, 0, 7
      PSET 1, 0, 5
      PSET 2, 0, 6
      ...
      PSET 200, 150, 5

Drawing those pics required some patience for sure. After all that effort, I had no idea how to make them move.

<comment><USER30> I, too, wrote entire games as a kid without knowing what an array was. :shudder:

</comment></comment></comment><comment><USER31> I felt like I'd stumbled into some sort of Bond villain's lair when I discovered PEEK and POKE in the BASIC manual for my TRS-80 Model I.

<comment><USER32> I discovered this for my Model III one morning, and my parents couldn't pull me away to leave for school. I had to try each one! You could change the shape of the cursor, the cursor blink rate, and even display a clock in the upper- right! That was a good day.

</comment></comment><comment><USER33> Ah the nostalgia of reading the entire guide to BASIC that came with my first computer, an Amstrad CPC6128. (Aside: The A in Amstrad stands for Alan and the S for Sugar, as in Lord Alan Sugar).

The days when it was possible to learn and memorise the entire built-in library of a programming language. I never did work out how to implement a linked list in Amstrad BASIC though.

<comment><USER34> I was surprised when finding my aunt oldest daughter Amstrad, that it came with a BASIC manual. I did not expect this to be marketed a programmable, more like game / word processor appliance. Also had a modem slot. I can't imagine what it would be to network in the 80s on such hardware.

<comment><USER24> It was terrific. I used my Amstrad CPC to dial up to bulletin boards: Preston ROS, Aspects BBS, Supe's Motel. Aspects was known to be one of the best in the UK, and it was consequently the devil's own work not to get the engaged tone.

Early on, connection speed was 300/300 or 1200/75\. Later I ended up writing my own terminal program, because I picked up a 2400 baud +compression modem from somewhere, and none of the existing software was fast enough to do the resulting speed of 4800 baud without dropping characters. To get the speed it had to talk directly to the UART in the serial interface, and then write the bitmaps directly to screen: no firmware calls anywhere, they were too slow. Heady days.

FWIW I don't think any of the 8-bit Amstrads came with a built-in serial port. But they were certainly available as add-ons for both the CPC and PCW.

<comment><USER34> My memories are blurry, but I clearly remember how surprised I was seeing mentions of modems on the manual.

Got me to do a little youtube digging : [https://www.youtube.com/watch?v=3WPMq80wYFY](https://www.youtube.com/watch?v=3WPMq80wYFY)

<comment><USER24> Ah, that's the Pace serial interface there. Yes, I remember that one.

<comment><USER34> Top comment mention a wifi board made recently. Retrofuturism.

</comment></comment></comment></comment></comment></comment><comment><USER35> Check the BBC Micro User Guide [1] for a very quick example of why so many of us that got computers at that time got into programming. By page 5 you're writing code (after the info on how to plug it in). Lines, colours, and sounds by pages 6 and 7. Page 168 is program optimisation techniques. Page 428: "An introduction to assembly language" ... 6502 assembler, amazing. That guide inspired me (aged 10) to start writing games, and gave me a career!

[1] [http://bbc.nvg.org/doc/BBCUserGuide-1.00.pdf](http://bbc.nvg.org/doc/BBCUserGuide-1.00.pdf)

<comment><USER36> Wow you guys were coddled. I had a hard time finding good Spectrum info in an ex-YU backwater, mostly just piecing it a bit at a time from magazines.

If I got access to something like Stack Overflow back then I think I would have fainted.

</comment></comment><comment><USER37> Well, there's always FreeBASIC, though it's more inline with QBasic and its derivatives. Can do some nice things in it, and there's support for C libraries.

</comment><comment><USER38> Oh my... so many good memories. The best part of the article was to find this link: [https://usborne.com/browse-books/features/computer-and- codin...](https://usborne.com/browse-books/features/computer-and-coding- books/). There's one of the books that I used to teach myself how to code when I was a kid. So many good memories :)

<comment><USER39> I still have this on my shelf! :D

</comment></comment><comment><USER40> > _They printed listings in the magazines, and enthusiasts would laboriously > type them line by line into their machines._

Guilty!</comment>


A Rust-based TLS library outperformed OpenSSL in almost every category - <AUTHOR> https://www.zdnet.com/article/a-rust-based-tls-library-outperformed-openssl-in-almost-every-category/ <comment><USER2> Hacker News readers would probably do well to read the actual post: [https://jbp.io/2019/07/01/rustls-vs-openssl- performance.html](https://jbp.io/2019/07/01/rustls-vs-openssl- performance.html)

It also comes with four separate posts that dig into the details, figuring out _why_ the discrepancy exists.

Additionally, rustls is a tls library built on top of _ring_. _ring_ is a project that is porting BoringSSL to Rust + assembly, bit by bit. BoringSSL was forked from OpenSSL. So there's common code ancestry here, especially around the primitives.

I have heard some people criticize these benchmarks because "those APIs aren't really used" or something; I don't fully understand this criticism myself, but they saw them as being "not real enough."

<comment><USER3> A small nit that bugs me in the original post

> The difference between AES128 and AES256 appears to be approximately 26%, > rather than the 40% one might expect (AES128 does 10 rounds, AES256 does 14 > rounds). There may be some limiting factor that prevents AES128 running at > the expected speed, or perhaps this CPU has extra area dedicated to making > AES256 faster.

The hardware in the CPU performs a single AES round, it does not dedicate more hardware for AES256. One who understands that AES-GCM is not just AES knows that the difference is due to the GCM overhead, that is the same for 128 and 256.

<comment><USER4> This is always a risk with blogging: you say something shortsighted or silly and don't realise until someone says "eh?" in a public forum. I've removed that paragraph; thank you for the correction.

</comment></comment></comment><comment><USER5> Very interesting!

Rust normally prevents a lot of memory safety problems, but those are not the only kind of security problem in a crypto system. Obviously the library has to correctly implement the spec (and expectations of users), which just using Rust doesn't guarantee. More importantly, a crypto library also has to avoid leaking crypto data through various side channels. Just using Rust doesn't help with that; "Crypto Coding" at [https://github.com/veorq/cryptocoding](https://github.com/veorq/cryptocoding) lists some rules to help address that.

Anyone know if rustls has worked on those issues as well? I notice that rustls uses ring, which asserts on [https://github.com/briansmith/ring](https://github.com/briansmith/ring) that "Most of the C and assembly language code in ring comes from BoringSSL, and BoringSSL is derived from OpenSSL. ring merges changes from BoringSSL regularly."

It doesn't matter if it's fast if it doesn't do things correctly...!

<comment><USER6> Yeah, but not surprising: OpenSSL is generally considered to be rather poorly written, from reinventing their own memory allocators, poorly, to layers upon layers of performance-sucking wrappers, to just bizzare and convoluted design decisons.

I'd be far more interested in seeing comparisons to, eg, BearSSL.

<comment><USER7> Note well: that was the prevailing (and probably correct) opinion a few years ago, but OpenSSL's quality has by most accounts improved dramatically over the last few years. I wouldn't talk someone out of using BearSSL, but if you're writing code that has to depend on a C-language TLS library, OpenSSL is a sane first choice.

<comment><USER8> I've reviewed OpenSSL code somewhat recently and agree that it's vastly improved.

Though, if you want something based on Rustls with C bindings (I have no involvement in this project) there is: [https://github.com/mesalock- linux/mesalink](https://github.com/mesalock-linux/mesalink)

That's OpenSSL compatible bindings into Rustls.

</comment></comment></comment></comment><comment><USER9> Impressive. I know Firefox uses NSS (its own TLS library) and not OpenSSL, but this article makes me wonder if Mozilla would consider using rustls in FF as Rust handles more and more of the FF code. Maybe it says something that NSS has few users apart from FF despite the obvious advantage of being maintained by a major organization.

Interestingly, the crypto code in rustls is by ring, a Rust crypto library. According to the ring github page, "Most of the C and assembly language code in ring comes from BoringSSL, and BoringSSL is derived from OpenSSL."

<comment><USER10> I'd much rather see Firefox use miTLS[0]. They already use HACL _[1] (miTLS and HACL_ are part of Project Everest[2]) in NSS[3], so I don't think it would be too big of a leap. Rust is really cool, but if you want to ensure that the implementation adheres to the spec, a language with formal verification is much better. That said, miTLS isn't finished yet, so of course it's going to take a while until anyone can actually use it.

[0] [https://mitls.org/](https://mitls.org/)

[1] [https://github.com/project-everest/hacl-star](https://github.com/project- everest/hacl-star)

[2] [https://project-everest.github.io/](https://project-everest.github.io/)

[3] [https://blog.mozilla.org/security/2017/09/13/verified- crypto...](https://blog.mozilla.org/security/2017/09/13/verified-cryptography- firefox-57/)

<comment><USER11> It looks like it's written in F#; that would make it harder to integrate with mozilla's c++/rust codebase. Not impossible surely, but possibly not worth it since in general an attacker has far more interesting avenues of attack than the ssl implementation; especially since it hasn't AFAIK had any high-profile vulnerabilities.

<comment><USER12> F* not F# [https://en.m.wikipedia.org/wiki/F*_(programming_language)](https://en.m.wikipedia.org/wiki/F*_\(programming_language\)). It compiles to C.

<comment><USER13> From the linked project page:

 _The stable version of miTLS including the new 0.9 release are written in F# and specified in F7._

Excuse my confusion.

</comment></comment></comment></comment></comment><comment><USER14> The implication here is that it does better _because_ it's written in rust. I doubt that's the case. I think it's faster because it's new, smaller (i.e. doesn't have to deal w/backwards-compatibility with previous versions or old protocols). More importantly, it uses the ring library for crypto, which is over half asm according to its github. Clearly, there's a lot of optimization there.

Regardless of the reason why, I'm very excited to see a better alternative to openssl. More competition will hopefully make all the projects better, and I wish the rustls guys the best of luck.

<comment><USER15> People do good things with rust. Therefore rust is a good programming language.

Could someone have done this particular good thing in another language? Absolutely. But that's not very relevant.

<comment><USER16> > Could someone have done this particular good thing in another language? > Absolutely

While this is true for many other tasks, I don't think there exists any other programming language that fits so well for safe and efficient protocol implementation (where experimentation speed is not that important)

</comment></comment></comment><comment><USER17> How much of these 'lol x written in Rust is better than y' is simply a matter of newer code generically improving on older poorly written software?

<comment><USER18> We're not talking about taking a venerable tool that's been sitting around for years and rewriting it though. We're talking about an actively-maintained and extremely highly-used library. I'm sure it's still bogged down by tech debt, but I'm also sure that any easy performance wins have already been taken.

<comment><USER19> A lot of time is spend on the assembler versions doing the crypto, which is why they get used by various other projects like ring, boringssl, and the Linux kernel.

Less or no time is spend on improving the performance of the SSL library. From the article, it seems that the SSL library might have easy fixes.

<comment><USER18> From the article it sounds like there are some simplistic reasons why OpenSSL may be slower, such as making an extra copy of the plaintext, but that doesn't necessarily mean that fixing it is easy.

</comment></comment></comment></comment><comment><USER20> Thread from a couple weeks ago: [https://news.ycombinator.com/item?id=20352296](https://news.ycombinator.com/item?id=20352296)

</comment><comment><USER21> If your coding in rust, need ssl, and are cross compiling, using rustls over openssl leads to simpler builds. This helped me simplify the rust -> aws lambda flow on a recent project.

</comment><comment><USER16> It would be cool if Firefox could switch to Rustls, but I can imagine that it will take a lot of time.

<comment><USER13> I'd prefer it to be a bit more battle-hardened before going into a widely used browser.

<comment><USER22> Agree. I'd rather have safe/secure over speed in this case.

</comment></comment></comment><comment><USER23> I would be interested in a comparison with BoringSSL.

</comment><comment><USER24> Was hardware AES and DH ever used? With hardware AES, it becomes hard to get statistically significant difference in between crypto libraries.

Unless you use a purpose made low CPU usage cipher like salsa 20, hardware crypto is just so much faster than software. It is like comparing software h264 implementations in 2019, and trying to make big news out of it.

Salsa 20 and derivatives looks to me a very promising cypher suite, but for as long as there is no hardware support for it, it will not see its niche even in resource constrained niches as even $5 smartphone SoCs nowadays can run hardware AES faster than any software crypto.

Another moment that needs note is that Salsa is still a relatively new and untried cypher, without much real world track record other than its use in Chrome. Poly1305 is an even less tried construct vs GMAC, with harder to imagine hardware implementation (it will be fair to say that most HMACs are hard nuts to crack for hardware implementation because of them using tons of LUTs.)

Second, Salsa is a work of just 1 man + few collaborators. Knowing the crypto community, this itself may be a reason for push back from it.

P.S. Question to people in crypto: why not to use some derivative of Salsa 20 as an HMAC instead of Poly1305 in Salsa-Poly combo?

<comment><USER25> Second, Salsa is a work of just 1 man + few collaborators. Knowing the crypto community, this itself may be a reason for push back from it.

Daniel J. Bernstein, to be precise, also author of Djbdns, Qmail, NaCl, Curve25519, ... Some of which he solo authored. So I'd take the quoted skepticism with a huge grain of salt.</comment></comment>


Show HN: Wonkavision – Screenprinting a Movie Scene - <AUTHOR> https://github.com/RCHowell/Wonkavision <comment><USER2> Very cool!! Sorry it didn't get more attention.

In last paragraph, you meant not enough contrast, I believe!

Thanks for the writeup!</comment>


Fabric hits 1.0 - <AUTHOR> http://pypi.python.org/pypi/Fabric/1.0.0

<comment><USER2> Changelog: <http://docs.fabfile.org/en/1.0.0/changes/1.0.html>

This is a major version, so note the backwards incompatible parts as well:

[http://docs.fabfile.org/en/1.0.0/changes/1.0.html#backwards-...](http://docs.fabfile.org/en/1.0.0/changes/1.0.html#backwards- incompatible-changes)

</comment><comment><USER3> I currently like pdsh (<http://code.google.com/p/pdsh/>) for doing remote sysadmin: it parallelizes very nicely, and I love being able to issue commands like "pdsh -w compute[000-100] yum update package" to manage hundreds of nodes at a time.

That said, I can see use cases for Fabric where you're implementing some complex logic in Python which you'd like to push out to your servers, rather than just doing simple shell commands or pre-pushing your scripts. But I can't tell how well Fabric parallelizes... being Python I'd expect it to be single- threaded :( , but I might be wrong.

Edit:typo

<comment><USER4> oh, so bash is suddenly multi-threaded now? :)

python does multiprocessing just fine: <http://docs.python.org/library/multiprocessing.html>

<comment><USER5> bash may not, but pdsh is (I personally used dsh, which also multiplexes ssh connections) and the child processes do not bear the lack of multithreadness of the parents :)

</comment></comment></comment><comment><USER6> Nice to see a new release, but there is still no official support for a parallel execution :(

There are some forks with a parallel support, but all of the ones which I have tried are pretty buggy / incomplete.

I have signed up for a Fabric PyCon sprint, hopefully I can help with adding / finishing the parallel support.

</comment><comment> old-gregg Am I missing something? I thought we're were going to get parallel execution, @task decorator and nicer control over 'env' in 1.0? There was a post about it just a few days ago. Right now I don't see anything from that in 1.0

<comment><USER7> That was a fork. While they'll hopefully get merged in, they're not currently in the official queue.

<comment><USER8> There are implementations of those features that are and have been in the official queue for a while.

</comment></comment></comment><comment><USER9> I use Fabric both at work and for my own projects. It's really simple to use, and I especially like that each function automatically becomes a Fabric command. Makes it easy to do "fab test", "fab migrate"... etc.

</comment><comment><USER10> Is Fabric basically capistrano implemented in python?

<comment><USER11> Well, no, it's different, but the idea is the same...

</comment></comment><comment><USER11> Last time I used Fabric I switched to Capistrano, no need to use this Fabric since the language of your deployment scripts doesn't really matters.

Lately I want to experiment with Chef using blueprint [1]. What do you think?

[1]: <http://devstructure.com/>

<comment><USER12> I've been using a simple Fabric script from [http://ericholscher.com/blog/2010/nov/8/building-django- app-...](http://ericholscher.com/blog/2010/nov/8/building-django-app-server- chef/) to automate Chef deploys. Blueprint tried to install a lot of nonsense on my box, and I decided that learning Chef proper would be a much better investment of my time.

<comment><USER13> DevStructure co-founder here, sorry to hear about your experience. Not sure when you installed blueprint, but we've recently open-sourced it and it's been ported to python. Should require minimal "stuff" to use it. Let us know if you have any questions or problems and again my apologies.

<https://github.com/devstructure/blueprint>

<comment><USER12> It was not a reflection on your product. FWIW, I tried it out about 3 weeks ago, using the setup.sh script. I'm not even in a position to critique Blueprint, as I was only migrating one single Linode instance to another, and not even anything complex.

Like you guys say, DevOps is hard.

<comment><USER13> Thanks for the clarification. We did open-source it last week (so you had an older version) and accounts are no longer required, you can download/build/run it. A lot easier to use should you choose to try again. If you need any help with the migration, we're always around the chatroom.</comment></comment></comment></comment></comment>


Ask HN: Question about default location sharing popup for iPhon App - <AUTHOR>

An iPhone is being developed on my behalf and there is an issue regarding the default location sharing popup that I was hoping someone here could answer.
My application accesses a users location and displays it on a map. Does apple's terms require the default popup to come up EVERY time the app (or the location sharing) is initialized?
For example, if i activate the app right now, it comes up. Lets say i exit out of it, and then come back in immediately, should we display the popup?
I am sifting through the guidelines and cant get a direct answer. Your assistance is greatly appreciated.
If you have any questions let me know.
leo <comment><USER2> from what i remember, the prompt is part of the framework and will ask the user to confirm twice before saving it as a default answer.</comment>


House with undulating floors keeps inhabitants on their toes - <AUTHOR> http://www.nytimes.com/2008/04/03/garden/03destiny.html?ex=1364875200&en=d2106bc2451e9c05&ei=5090&partner=rssuserland&emc=rss&pagewanted=all <comment><USER2> Some of the other work by this architect/designer couple is liveable: <http://www.flickr.com/photos/88798845@N00/15233067/>

However, this house is a an OSHA-nightmare.

Let's compare this with Nintendo DS' Brain Age. Brain Age is a game that challenges your mind with clever puzzles, helping, in theory, to keep you and your mind younger.

The house is similar in that it supposed to stimulate your mind so that you avoid obstacles/don't hurt yourself but

The difference between this scary house and Brain Age is that Brain Age is fun and a game...

"Comfort, the thinking goes, is a precursor to death; the house is meant to lead its users into a perpetually "tentative" relationship with their surroundings, and thereby keep them young.

"The architect Steven Holl, who has known the couple for at least 15 years, said their architecture is intended to evoke a youthful sense of wonder. "It has to do with the idea that you're only as old as you think you are," he said."

Wonder if your homeowner's insurance would cover accidental death..

<http://www.brainage.com/launch/what.jsp>

</comment><comment><USER3> Someone is going to get calls from Google Headhunters pretty soon...

</comment><comment><USER4> the article fails to answer the biggest question: how did two artist/philosophers afford to build a big crazy house in the Hamptons?

<comment><USER5> "The house, which is still unoccupied, was commissioned in the late 1990s by a friend who sold the property to an anonymous group of investors after the project dragged on and costs mounted."

I think I'd remain anonymous too...</comment></comment>


Apparently No One Cares That Much About Ethnic Cleansing - <AUTHOR> https://slate.com/news-and-politics/2019/11/china-uighur-ethnic-cleansing-impunity.html?via=section_features <comment><USER2> Given the West's absolute addiction to everything Chinese:

\- Western governments and their affair with selling bonds to China

\- Western startups and their addiction to Chinese capital

\- Western tech giants and their addiction to access to the Chinese market, at all costs

\- Western universities and their preference for rich, Chinese international students

\- Hardware manufacturers and their dependence on Chinese components

\- Consumers and their "must have" goods produced in China by most of the above companies

\- Hollywood and its reliance on Chinese funding

\- etc. etc.

There is no way in hell you are going to see much of a movement against the country or party in these parts, no matter what they get up to. In fact, with the sheer level of influence China has in this section of the globe, I wouldn't be surprised to see criticism of their actions being re-framed as racist/colonialist/the rest of the "ists" by the crew you'd expect it from over here.

That those in the West proclaiming themselves to be activists of social justice focus their efforts on a handful of people in migrant boats trying to enter Europe, or people entering the US illegally, or "microaggressions" in Western society, over the real injustices in the world should point to who is controlling the narrative and holding the purse strings.

<comment><USER3> These are dark times when the wealthiest, most pampered, and (importantly) bored people on the planet are frustrated about 'microaggressions' while China does what it does.

I mean, I never took the people who complained about microaggressions seriously, but I did start to hypothesize why the phenomena even came into existence. I can't find a better hypothesis than that they are just supremely bored with their lives.

</comment></comment><comment><USER4> No one will say it loud but I am thinking many people quietly agree (in principle) with what China is doing. The rest doesn't care.

<comment><USER5> I don't think the people who agree with what china is doing have any fear of speaking up.

</comment></comment><comment><USER6> Perhaps using a term less euphemistic than "ethnic cleansing" would help people react more appropriately.</comment>


Movie franchise earnings comparison over 20 years - <AUTHOR> https://www.reddit.com/r/dataisbeautiful/comments/bgf3ye/oc_franchise_earnings_comparison_over_20_years <comment><USER2> Amazing visualization. I didn't know that MCU > Star Wars + Harry Potter. Also thought that DC had completely messed up the movie franchise but looks like they still clawed out $2B. Not that bad in my books.</comment>


Why I TDD - <AUTHOR> https://twitter.com/search?f=realtime&q=%23whyitdd&src=hash <comment><USER2> Looks like some sort of cult mass prayer :).

<comment><AUTHOR> The key point for me is that most of the recent criticisms I've read about TDD have almost always been about TDD as a testing tool. If you look at the reasons folk list on why they do TDD testing is rarely, if ever, mentioned.

For me TDD is a design/development practice, not a testing practice. That's where it delivers value for me.</comment></comment>


Show HN: A Collection of most useful and common ReactJS Libraries/Components - <AUTHOR> https://applibslist.xyz/ <comment><AUTHOR> applibslist.xyz is a curated collection of trending and useful libraries and components for ReactJS, which are actively maintained and contributed by developer community</comment>


Microsoft Is A Total Mess ... And That's Why No One Wants To Be Its New CEO - <AUTHOR> http://www.businessinsider.com/wsj-microsoft-ceo-search-2014-1

<comment><USER2> Why would anyone want to work for the founders that are still on the board of directors.

Who wants to be compared to Bill Gates in everything.

Worse yet would be putting up with a buffoon like Ballmer on the board. They need to kick "Developers Developers Developers" to the curb.

Microsoft has peaked.

Google is the new Microsoft especially since they will work so closely with the NSA. That virtually guarentee's they will pushed by the govt as the best solution for everything.

It's much easier to monitor then all these random desktops that Microsoft presents them with.

</comment><comment><USER3> People have done far crazier things than that for money.</comment>


Rust and C++ Interoperability in Chrome - <AUTHOR> https://www.chromium.org/Home/chromium-security/memory-safety/rust-and-c-interoperability <comment><USER2> > No need for the "unsafe" keyword unless something is known to be less safe > than normal C++.

> For a Rustacean, this is controversial - all C++ is unsafe!

Isn't this just a fundamental misunderstanding of what unsafe really means, and as such a nonsense goal that doesn't gain anything?

Unsafe is a Rust language definition, and defines whether the _rust compiler_ can vouch for the safety of some code. As such, calling to a library in some other language will always be unsafe, by definition, because the Rust language cannot vouch for it.

If it makes you feel better, replace "unsafe" in your head (or with a macro) with "rustc_cannot_vouch_for" and carry on with your day. It means the same thing, and isn't really telling you that your C++ code sucks even if it looks like it at first glance, so who cares?

If you really want to reduce the unsafe keyword from being seen in most regular code, you create and interface that maps the C++ function and exposes it as a rust function, and you've hidden away your unsafe usage to one spot per function. If you have enough confidence in your C++ code, there's no downside to this (and if you don't, then maybe you shouldn't be complaining that unsafe is unneeded).

<comment><USER3> > ... known to be less safe than normal C++.

Oh... no, no, that's... very unsafe lol.

Jokes aside, making that their #1 goal was very strange. Agreed it appears to be a fundamental misunderstanding of what "unsafe" means. It doesn't mean that it's literally not safe to call that function, just that it's unchecked. "unchecked" might be a better annotation come to think of it.

<comment><USER2> > "unchecked" might be a better annotation come to think of it.

Yeah, it's come up before in discussions here. Depending on the context you're coming from/working in, unchecked either makes more sense, or less sense than unsafe. When working within Rust, unsafe makes sense, it maps to how people think about what they are doing, because rustc is checking everything. When working between Rust and other languages/libraries, it's a bit less accurate, and "unchecked" makes more sense.

</comment></comment></comment><comment><USER4> > This seems to present some C++/Rust interoperability challenges which nobody > else has faced.

Is this different from the Firefox integration with Rust in some meaningful way?

It looks like the cxx library is going to be critical for this. I'm curious how helpful others have found cxx for interop with C++?

> For a Rustacean, this is controversial - all C++ is unsafe! But "unsafe" > should be a really bad code smell. If "unsafe" is needed for all C++ calls, > there will be thousands of them, and the "unsafe" keyword will lose its > meaning.

I don't think the attitude about unsafe usage differs from the general Rust community. If there's a lot of it, then it definitely is a code smell.

<comment><USER5> Can't you just do a:

          #define CPP_CALL unsafe

in the Rust equivalent to annotate "unsafe" cpp calls from Rust?

"No boilerplate or redeclarations. No C++ annotations. Ideally, no allowlist."

This seems like an unpractical approach. How do you even call C++ code from Rust without extern "C" linkage.

<comment><USER6> Really, your text macro substitution is missing the broader point.

Hiding the word "unsafe" doesn't make it any less unsafe.

The Rust compiler can't guarantee that the C++ code being called doesn't have use-after-free bugs or buffer overflows.

The Rust compiler can't guarantee that pointers being returned from C++ code aren't just wild pointers that point in the middle of nowhere.

The Rust compiler can't guarantee that the C++ code isn't mutating into an immutable reference.

The Rust compiler can't guarantee that the C++ code isn't holding onto a reference to an object that it will later mutate when Rust thinks it is now the sole owner of that object.

The Rust compiler can't guarantee that the C++ code isn't sending un-Send objects across threads, or that it isn't deallocating objects that it isn't supposed to deallocate.

Rust makes _a lot_ of guarantees about code written in Rust, which is why people are so passionate about it. The Rust compiler _feels_ like having the world's best static code analyzer at your fingertips. It's really nice.

C and C++, on the other hand, are each full of an assortment of powerful footguns. _Well-written_ C or C++ code interops very nicely with Rust, but the problem is that programmers are only human, and humans have been repeatedly shown to make mistakes.

So, calling C++ code is unsafe, and unsafe is a code smell because it is an opportunity for guarantees to be violated, which is undefined behavior.

Ideally, you build an abstraction around the unsafe interop layer that rigorously enforces every requirement that the C or C++ code expects (but that the C and C++ compilers cannot enforce), so that the external code will behave as well as it can.

The Chromium document is right to call their idea controversial. Hiding the unsafety of the C++ code without actually doing anything to protect against malformed calls to that C++ code is a loaded footgun. It might be the right call for this specific case, though.

<comment><USER7> I disagree; All of the things you say about C++ code also apply to unsafe Rust code. There's an unsafe keyword that allows using that unsafe code, and when you use it, you are asserting to the compiler that "I promise this code is actually being used in a safe way". All this document says is that the C++/Rust boundary should be considered another place where you are asserting "I promise this code is actually being used in a safe way".

<comment><USER8> I think the issue is that rust unsafe means "does something sketchy" whereas even perfectly safe C++ would have to be annotated unsafe.

<comment><USER9> Rust unsafe doesn't mean "does something sketchy". It means "compiler I know what I'm doing". It's equivalent to casting raw C pointers. You are supposed to know what you are doing when doing that, but you will be on your own. It might still be perfectly safe, but the compiler can't tell.

<comment><USER8> Sure, but it does indicate something likely to be wrong, relative to normal rust code. If every C++ function is unsafe then it becomes less clear where the actually unsafe rust bits are.

<comment><USER9> C++ has made it very painless to upgrade from C, by being (mostly) a superset. It's so painless that many codebases haven't really upgraded and it's common to see C-isms sprinkled around larger code bases. Some classes written decades ago can survive the years written in horrible outdated style. For some that might be a feature, but for the quality (or safety) of the code it isn't.

Yes, when there is too much unsafe in a Rust codebase then the unsafe label inflates and the safety guarantees aren't as good. But the conclusion of that shouldn't involve changing definitions of what's unsafe and what isn't, but using less unsafe overall.

Rust can interface with C++, but it isn't well suited for too intimate interfacing. That's not where its strengths lie.

<comment><USER8> I think that's a different goal from what chrome is looking for. It sounds like they want to be able to use their utilities and other code written in C++ from within rust, not integrated on a macro level.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment> Paul-ish Back when I was an intern at Mozilla it was a real pain (in my opinion) to call between C++ and Rust. This was before bindgen and cbindgen, and certainly CXX.

Eg if you have a heap allocated thing that is passed between Rust and C++, who frees it? I ended up hacking something together, but it didn't feel right.

<comment><USER10> >if you have a heap allocated thing that is passed between Rust and C++, who frees it?

Isn't this an issue regardless? Forget crossing the rust/c++ boundary, lets say you pass something to another class in c++, you need to have a contract of who frees what when, right? Maybe I'm not understanding the issue.

<comment> Paul-ish Inside both Rust and C++ there are very well developed tools (eg smart pointers) for dealing with memory allocations. These tools were never written to be compatible with each other, so you lose them at the language boundary.

<comment><USER10> That makes sense. I do 99% C, so any time I even have to think about C++ it unfortunately turns into C with classes rather than C++, so I'm really not as familiar with the smart pointer options.

</comment></comment></comment></comment><comment><USER11> Hm, I'm a Googler working on the chromecast platform and a Chromium committer who thinks Rust Is Pretty Neat. I'll look internally as well, but who can I talk to about helping out with Rust adoption in the context of the chromium codebase?

</comment><comment><USER12> Question about the organizational context here. My understanding is that Chromium is an open source project. In practice though, when the document says "we" is it talking about mostly Google engineers? I read the document as indicating that there's a serious possibility of more widespread Rust usage, especially that last sentence

 _If we become convinced this sort of interoperability is possible, we'll revisit widespread use of Rust in Chrome, and at that point we plan to work hard to achieve this with robust production-quality solutions._

Would it be wrong to take away from this that in some teams within Google, using Rust in places where C++ would have been used, is something that is being considered seriously?

</comment><comment><USER13> So building Chromium becomes even more complex. Understanding the build system alone is a major achievement; I even had to build a tool for that: [https://github.com/rochus-keller/gntools/](https://github.com/rochus- keller/gntools/). Unfortunately that's only half of the rent; it also needs hundereds of Python scripts; and now also crates will be added.

<comment><USER14> The post is how they are _not using rust_ , how could you possibly have come to the conclusion that the builds are going to get more complicated?

<comment><USER15> Because they're clearly interested in possibly doing so in the future?

</comment></comment></comment><comment><USER16> I integrated some basic CEF stuff (enough get to get a basic browser working) into a Rust codebase ([https://github.com/hamaluik/cef- simple](https://github.com/hamaluik/cef-simple)). It was a massive pain at first, but much easier once you give up on the safety and "idiomacy" of Rust and accept that you have to write in more of C/C++ style. For the parts that can't be written purely in Rust, it ends up being not really any more painful than writing it in C++ anyway.

</comment><comment><USER17> I hope someday maybe we have a browser completely written in Rust.

What's the point of using Rust in a C++ code base if C++ is the 800lb gorilla as the article implies. If C++ is so important, then just stick to that?!

<comment><USER18> That was the goal with Servo, but Mozilla axed them [https://twitter.com/directhex/status/1293352458308198401](https://twitter.com/directhex/status/1293352458308198401)

<comment><USER19> Servo was always a research project around writing a _rendering engine_ and not an attempt to create a whole new _browser_ product.

<comment><USER20> Webrender would work better as the complete OS interface than as an engine for one browser/app.

</comment></comment></comment></comment><comment><USER21> This is all very clever, but it has certain really, really fundamental problems.

1\. The main program will remain C++ (or anyway Google's hobbled subset). New code you choose to get done in Rust will be lower-level code, implementing specific new features, or re-implementing low-level stuff too toxic to fix. So, the main task is _not_ Rust calling into C++ code, but C++ calling Rust. That doesn't mean the Rust code won't ever need to call out to utility code, but: You are coding in Rust for an actual, you know, _reason_ , right? Maybe that utility stuff should be RIIR, first? Otherwise what was the point, again?

2\. It is all very well to talk about Rust calling C-like functions and virtual functions, but that only takes us up to 1985. We all know (I hope) that the overwhelming majority of useful power in C++ code is in features wholly inaccessible to Rust, even in principle. How will Rust do overload resolution? Inlines? (Also 1985.) Template instantiation? Exception handling? (That takes us to 1992.) Template function overloading and partial specialization? (1998). I could go on, right up to 2020.

There are other fundamental problems, but this seems like enough for now. No sense piling on. At least point 1 makes point 2 less a problem.

</comment><comment><USER22> I wonder how this compares to Mozilla's approach when they did something similar with Rust, Firefox and servo.

<comment><USER23> Mozilla's uses a combination of [https://github.com/eqrion/cbindgen](https://github.com/eqrion/cbindgen) and [https://github.com/rust-lang/rust-bindgen](https://github.com/rust-lang/rust- bindgen) depending on the direction of interop. These tools don't provide the safety guarantees of [https://github.com/dtolnay/cxx](https://github.com/dtolnay/cxx) but the also both predate cxx and C++ doesn't have much in terms of safety guarantees to begin with so the bar is pretty low.

<comment><USER24> It's also worth mentioning that Mozilla tends not to use a lot of standard C++ types, using nsTArray instead of std::vector or nsA?C?String instead of std::string. This makes the porting of APIs using arrays or structs easier, since Mozilla owns the ABI rather than needing to worry about different standard libraries having different ABIs.

<comment><USER25> C++ interop with C++ can be a pain. E.g. even with the same version of the same compiler, GCC can have different options enabled that affect the layout of some types.

<comment><USER21> That is the same in _all_ languages mature enough to have variant options. Rust included.

Therefore, a tendentious distraction from the topic. Chris, I shall expect better from you in the future.

</comment></comment></comment></comment></comment><comment><USER26> Do they really need to access thousands of C++ API calls from Rust? Doesn't this defeat the purpose of writing safe code in Rust? This smells of "not invented here" which applies to Google projects pretty often.

They should focus on integrating Rust in portions of the API instead of exposing a gigantic unsafe API surface, essentially making all their code unsafe. Unless the Chrome codebase is really such a mess that they can't do anything without exposing this giant API surface. In that case they should rewrite it to... not do that.

"We can't use Rust unless it allows us to write all our code in C++ without showing unsafe warnings"

<comment><USER27> > Do they really need to access thousands of C++ API calls from Rust?

Yes. It's turtles all the way down. Applying this line of thought to its logical conclusion, it wouldn't be worth it until we have written the OS itself and all firmware in Rust.

<comment><USER28> Just within the process. Between processes or process and kernel, there are already runtime checks, so Rust isn't contributing safety so much quality.

</comment></comment></comment><comment><USER29> They should probably look at how mozilla does it. From experience doing something similar, things get simpler when you write your code using handles rather than pointers but that's not how chrome is written.

[https://floooh.github.io/2018/06/17/handles-vs- pointers.html](https://floooh.github.io/2018/06/17/handles-vs-pointers.html)

</comment><comment><USER30> As someone that deals with a chromium-based codebase everyday, i dont think this is a good idea at all.

Unnecessary overcomplication on the codebase, making it more difficult to understand. (Rust and C++ are complex beasts)

The only thing i could think of, is to replace the tools that are mostly in Python.. But this will be a lot of work.

I guess maybe Google wants to employ good Rust enginneers and need to have some "playground" for them.

Swift on the other way, will have native C++ interop, and soon will give the ability to manage the memory ownership the same way C++ and Rust does (not just defaulting to ref-count)..

Once Swift have those properties we will have one more good contender in the same arena as C++, Rust and Zig.

<comment><USER31> I doubt the point is to offer people a playground but rather to find a way to write new code in a language that is memory safe by default. Browsers are notoriously plagued by bugs related to memory safety so there's quite a lot of motivation for at least considering this path.

<comment><USER30> That is the problem with default narratives, they dont adapt well to every case.

Chromium codebase is a massive codebase. It works, its efficient and fast, its sophisticated and complex, its well tested, had all sort of bugs that was taken out of them. Its really well written C++ code with modern ownership semantics. So a lot of mistakes that are used as boogeyman to convince people to use Rust are barely problems you really face.

And no matter what wonders Rust promisses, a lot of bugs would get back there in case of rewriting things.

Rust can make a very good point when the thing to be rewritten is in C (if is not a billion dollar codebase like Linux). But with big codebases, well written and modern C++ it doesnt make sense at all.

I get it why someone would start a new project in Rust though.. but the things dont add up when we talk about big codebases already coded with good C++ practices.

<comment><USER32> > So a lot of mistakes that are used as boogeyman to convince people to use > Rust are barely problems you really face.

[https://bugs.chromium.org/p/project- zero/issues/list?q=produ...](https://bugs.chromium.org/p/project- zero/issues/list?q=product%3Achrome&can=1)

This year alone saw 2 issues from Project Zero in Chrome that would have been prevented by Rust - both OOB accesses, one with a helping of data racing.

Chromium is an incredibly security-sensitive piece of software, and that really is an excellent fit for Rust. It's not a boogeyman argument and the Chromium team themselves are the ones pursuing it, it's not being forced on them.

<comment><USER30> I have no doubt that Rust could save some sort of bugs. If you read all the comment i´ve made, you will see that we are talking about a massive codebase already coded in C++.

Giving the time it is alive, all the engineering hours, investiments, tools, etc.. most of the bugs that Rust could have prevented right on the beggining are already covered (Chrome also uses fuzzers and static analysis tools to automate C++ code)

> This year alone saw 2 issues from Project Zero in Chrome that would have > been prevented by Rust

Thanks for making my point even clearer. If you really knew the size of the codebase, having only 2 issues on Project Zero is kind of a compliment to Chrome.

By the way, it was yesterday, that i´ve saw a research with fuzzers applied in C, C++ and Rust codebases.

In that research, Rust had the same overall count of bugs and even some 'zero day' sort of ones not any different from C++ and C codebases (maybe just better than the C one).

Its a pitty i can find where it is (I´ve saw it on Twitter, but its pretty recent).

> Chromium is an incredibly security-sensitive piece of software, and that > really is an excellent fit for Rust. It's not a boogeyman argument and the > Chromium team themselves are the ones pursuing it, it's not being forced on > them.

A Chrome started from zero in 2020? probably.. but thats not the reality here. Millions of lines of C++ code, and its not just a matter of language, but the knowledge and people with the know-how to write those pieces..

Thats why im saying is not worth it..

<comment><USER33> You also have to consider the huge investment that testing takes. Not only person days spent writing tests, but also infrastructure costs for running fuzzers, huge test suites and so on. And although the code base is already there and tested, it constantly changes, so there is no way to just incrementally test it. At some point you have to make some advances in the way you approach software development, not everything can be handled by brute force.

<comment><USER30> It would cost much more to rewrite in Rust.

Again thats why im saying that if the project would start now in 2020, all of those would be pretty good points. Right now is too late for that.

As another example, you can get just the V8 VM for instance. For start, with the ammount of solid code out there it would be nuts to talk over a rewrite..

Now imagine if we add to that, that the knowledge on JIT compilers is so difficult to grasp, that you would also need to have those same great engineers in the new language/platform you are planning the rewrite.

Giving the age of Rust, and giving you already have a bad time of finding those in the much older C++, imagine the time it takes to have the same quality people in Rust.

I know a lot of people are bully about Rust, but in reality things are not that simple.

(On the bright side, is not that hard to taught a C++ engineer to code in Rust)

<comment><USER34> If you care about security, it is much easier to write non-exploitable code in Rust than in C++, and you can hire accordingly.

Actually, the people who are really experienced at writing secure code in C++ understand that they can't do it reliably, and an increasing number of them (like me) would much rather write Rust code instead for that reason. So for secure code the hiring advantage is tilting away from C++ towards Rust.

<comment><USER35> Yet once the Chromium team goes down that Rust to C++ FFI route, they will encounter the same old bugs outlined in this paper. [0] They might as well fork Servo and create their own engine from that, but even that is still a prototype worked on for years with zero C++ at least.

It's too early to see how the Chromium team will begin to work on this given it's only a plan, but maybe the unsafety and security issues are enough motivation to actually use Rust to C++ interop or a rewrite. But once again, this has been tried by some other projects and by just looking at the effort of a rewrite, they later concluded that it is not worth it. [1] [2]

Even better, just improve Servo instead. But I guess they would rather create their own fork, just like they did with WebKit.

[0] [https://arxiv.org/pdf/2003.03296.pdf](https://arxiv.org/pdf/2003.03296.pdf)

[1] [https://blogs.dust3d.org/2019/03/13/why-i-rewrote-the- mesh-g...](https://blogs.dust3d.org/2019/03/13/why-i-rewrote-the-mesh- generator-of-dust3d-from-rust-to-cplusplus/)

[2] [http://way-cooler.org/blog/2019/04/29/rewriting-way- cooler-i...](http://way-cooler.org/blog/2019/04/29/rewriting-way-cooler- in-c.html)

<comment><USER34> None of this logic follows. Paper [0] categorizes bugs in unsafe Rust code. "There will be some bugs in FFI code" does not imply "no benefit to using Rust if there is C++ FFI". Many projects, including Firefox, have found Rust is really helpful even if you have C++ FFI.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER36> TIL Rust doesn't have function overloading. But actually not sure whether this is a good or bad thing.

<comment><USER15> I've been using it since pre 1.0 and I couldn't tell you either. (Traits get you most of the way there but you'd see them exist for no other purpose which is just boilerplate imho.)

</comment></comment><comment> Const-me Looks way too complicated. I think the reason is rust is not good at OOP. Compare with my C# to C++ interop library, it can easily pass arbitrary complicated types both ways: [https://github.com/Const- me/ComLightInterop](https://github.com/Const-me/ComLightInterop)

<comment><USER37> The problems listed aren't the oop, they are the memory and thread safety rules of rust, that prevent all the null pointer dereferencing and leaky memory that a "dumb" C++ wrapper allows.

<comment> Const-me Here's a quote from the article:

> We think the hardest part of this is imagining a safe way to pass types > between Rust and C++. That requires auto-generated shim code on both the > Rust and C++ side.

I'll be very surprised if they'll be able to make a production-quality solution. The languages are just too different, and Rust's OOP support is one of these issues.</comment></comment></comment>


Ask HN: sound - electricity? - <AUTHOR> I was thinking about doing a little wind power project, and thought it would be cool to not use a turbine... so, what's a cheap and easy way to generate electric power from sound?  (Maybe using those little piezoelectric buzzers?) <comment><USER2> When it comes to power from sound, be warned that results are likely to be rather disappointing - there's a reason microphones and guitar pickups benefit from such highly sensitive pre-amps! If you're just looking to do it out of intellectual curiosity, though, then piezos will at least get you somewhere - like DC motors, they're a 'two-way' thing; put power in, get vibration (sound), put in vibration, get (a little) power. You can often scrounge them from old toys, too, so they might be worth a look.

Other than that, there are a few interesting projects out there looking at alternatives to turbines for generating wind energy - my favourite would have to be this one:

[http://www.popularmechanics.com/technology/industry/4224763....](http://www.popularmechanics.com/technology/industry/4224763.html?series=37)

Cobbling one of those things together could make for an interesting and fairly cheap project - if you find the time to do it then I'd love to see the 'vital statistics' of how much juice it'll give you!

<comment><AUTHOR> Thanks, that looks awesome. It's hard to find any good guides online (wikipedia links to one that makes no sense at all) but it seems like an easy project to do without instructions, since all it takes is a couple solenoids and a magnet or two.

Just experimenting with paper strips, it seems like the frequency depends on the width between the membrane and the base. Does anyone know if/why this is true?

</comment></comment><comment><USER3> I'd say, depending on your scale, the best power generation you're going to get out of sound would be to use a very large and light membrane to catch the sound and tie it to piezoelectric cells.

You want to produce the maximum deflection possible on the piezoelectric cells as this will produce the largest amount of electrical energy. This will probably be cheaper to do by connecting something like a mylar sheet (a cheap place to look would be the foil wrapping-paper at the dollar store) to some piezoelectric cells.

I'm unsure if piezoelectric cells alone would receive enough force to produce a noticeable effect.

An alternative would be to produce a very large cone and place a piezoelectric cell in the tip of the cone. This would perhaps be a lot less work. However I have a greater understanding of electrics than acoustics, so I'm unsure if it would be better to channel the sound to a small surface or to simply use a large lightweight membrane.

Hopefully this helps you some.

</comment><comment><USER4> Wind essentially IS sound - but with a very low frequency.

Sound is air moving, wind is air moving.

You can use a turbine that spins forward and back I suppose. You'll have a hard time with this - you'll need to match your turbine to the frequency of the sound. Using a microphone works, but only for frequencies in human range.

If you want to catch more energy you'll need to handle infra-sound. Meaning a massive microphone.

</comment><comment><USER5> You may want to check out this guys work: <http://www.unews.utah.edu/p/?r=053007-1> "heat -> sound -> electricity"

</comment><comment><USER6> I had not thought of this and I congratulate you on being so clever to think this up. I don't know if it would work but it's well worth considering.</comment>


Digital Revenue Exceeds Print for First Time for New York Times Company - <AUTHOR> https://www.nytimes.com/2020/08/05/business/media/nyt-earnings-q2.html <comment><USER2> All politics aside, the quality of the writing, and especially the editing, has plummeted in the past decade at least. The NYT used to set the gold standard. Now it's shocking to read, and I don't mean the content.</comment>


Best personal finance software - <AUTHOR>

I'm looking for a budgeting solution that will allow me to input my current net worth (WITHOUT actually connecting to my bank etc), input my (theoretical) expenditures and allow me to play with the numbers to determine things like; a) How long can I live off my current net worth b) How much does it cost me to live each month and so on and so forth. Any ideas?
  I should clarify I don't want to use excel/spreadsheets, or store information in the cloud. Also, free or close to free. <comment><USER2> GnuCash <http://www.gnucash.org/> works well as a simple (personal) accounting system and I believe it will do what you are asking. If not, you can augment it. :-)

The user interface is somewhat quirky - I'm not an accountant, so part of that may be just my lack of knowledge. The interface it isn't a clone of QuickBooks, so accountants will find it quirky too.

One thing that I found really nice about GnuCash that I didn't find in QB (as of a couple revisions ago) is that you can make sub-accounts. I've used this for "restricted funds" that are co-mingled in a single savings or checking account. GnuCash rolls up the sub-account balances into the primary account's balance so you can reconcile your bank statements directly against the account/sub-accounts.

<comment><USER3> GnuCash is great on Windows and Linux but is very flaky on Mac OS, if that's a concern.

</comment></comment><comment><USER4> You might want to check out <http://xpenser.com/> . It does a great job with capturing and reporting on your expenses, but doesn't do the planning part (how long can I live off my current net worth).

It's free, and lets you capture expenses using iphone, android, email, sms, voice, im, twitter, etc. You can export to GnuCash, Quicken, QuickBooks, Excel, etc.

</comment><comment><USER5> Do you really need an ad-hoc program for such simple requirements?

Probably a spreadsheet (excel or any free alternative) can handle it easily (damn, even a calculator and some paper is more than adeguate!).

Want something free that can entertain your mind? do this with emacs and org- mode. Org's tables support formulas.

</comment><comment><USER6> What about: <http://www.pulseapp.com> ?. I'm using the free version and I think it's okay for my needs.

<comment><USER5> Sorry, but where's the free version? <http://pulseapp.com/signup>

<comment><USER6> Look below: <http://create.pulseapp.com/signup/free>

<comment><USER5> Hey, that was small! :-D

thanks

</comment></comment></comment></comment><comment><USER7> I used getharvest.com ... to input my expense from my iPhone, and at the end of each month I reviewed how/where I spent my $$$ each month.</comment>


Linus Torvald's rant against C++ - <AUTHOR> http://lwn.net/Articles/249460/ <comment><USER2> As someone who prefers C over C++, I agree with some of what Linus says here but I wouldn't call things like STL and Boost "total and utter crap".

<comment><USER3> Indeed, exactly what is the "C" way of elegantly introducing dynamically-sized arrays and Unicode strings? Memory management? You use external libraries of your choosing. In my mind stl::vector and stl::wstring (basic_string<wchar_t>) are perfectly good choices for that, in an otherwise completely C context. std::auto_ptr... not so much.

</comment></comment><comment><USER4> _sigh._ can you imagine matz, guido, or bjarne having a rant like this? i can't.

<comment><USER5> What's your point? I don't mean to be a jerk, but ... what is your point?

The designers of the Ruby, Python, and C++ have (perhaps) more cordial online personalities than Linus ... so what?

And the whole "rant" is taken a bit out of context...

A patch was submitted, which used C++ in a C-only project, then some guy (Kakurin) comes out of nowhere and says "you should be using C++ on your project", and Linus replies with reasons that they are not going to use C++.

So it's not, "C++ is stupid;" it's closer to "no, we are not using C++ for Git" ... even if what he said was "C++ is stupid."

To get a better picture of the discussion, you should really read the preceding comments, as well as the follow-ups.

The root of the thread can be found here: [http://article.gmane.org/gmane.comp.version- control.git/5764...](http://article.gmane.org/gmane.comp.version- control.git/57643)

The "hair trigger" might be explained by the fact that Linus' other project, the Linux kernel, is also C-only and I'm sure that this (re: "letz use cpp plz") has come up before. And Linus _is_ a jerk... whatever.

Personally I think that he articulated his point reasonably well, if a little forcefully.

Besides, if C++ would really have been That Much Better™, he's welcome to use it; just not dictate language Linus uses to write _his_ project with... which is basically what Torvalds said. I mean, it's open source, after all.

PS. The guy who made the comment appears to (despite the GMail address) have worked at Microsoft at the time, for what that's worth.

PPS. The real " _sigh_ " is that this post is year old, out of context link bait.

<comment><USER4> so, "online cordial personalities" are pretty much a prerequisite for being a good leader. and even if you want to find fault with this particular example, there are plenty more where linus acts exactly like this.</comment></comment></comment>


Ask KN: What email service should I choose to use? - <AUTHOR> Hello,
I forgot my password at Google mail. They do not allow me to reset. This is an error of the password recovery system, but they didn't listen to me. I want to switch to another mail service provider. Please advise me to choose one. I tried creating my own mail server with DigitalOcean but they didn't open port 25 for me, so I immediately deleted the droplet. I'm really confused. The email has never been so complicated.
Thank you, guys. <comment><USER2> I'm preparing for what happened to you. Basically:

1\. Get your own domain. 2\. Get a half decent provider (zoho has a free plan, I use them they see quite good)

Keep a zero inbox by deleting and downloading emails.

If you get locked out again just change your DNS. Just make sure you don't get locked out of the domain name!

</comment><comment><USER3> I would say one of these providers:

* [https://www.privacytools.io/providers/email/](https://www.privacytools.io/providers/email/)

* [https://web.archive.org/web/20190619003906/https://www.priva...](https://web.archive.org/web/20190619003906/https://www.privacytools.io/providers/email/)

Ultimately free without encouragement to pay is not good as it will involve the platform monetizing by selling your data in some way.

Should also note at the moment, not all providers are equal, for example posteo.de doesn't allow you to use your own domain whereas some of the others do. Protonmail doesn't currently have calendars although that's coming soon [https://www.reddit.com/r/ProtonMail/wiki/dev- status](https://www.reddit.com/r/ProtonMail/wiki/dev-status) Tutanota does not allow for IMAP/SMTP (you must use a browser or their client).

There's also this issue where privacytools.io plan to expand the information about each provider. [https://github.com/privacytoolsIO/privacytools.io/issues/603...](https://github.com/privacytoolsIO/privacytools.io/issues/603#issuecomment-456400331)

<comment><USER4> I quite like Fastmail. I switched from Gmail five years ago and have had no complaints.

<comment><USER3> > _I quite like Fastmail. I switched from Gmail five years ago and have had no > complaints._

I have heard fastmail has a rather good user interface. Gmail's is terribly slow these days.

They also are the only provider I know of that currently implements ARC (Authenticated Received Chain) [http://arc-spec.org/](http://arc-spec.org/) and are big proponents of JMAP [https://jmap.io](https://jmap.io)

If you're not bothered by the fact they operate in a FVEY country US/AU then they are an option too.

What I do like about Mailbox is they let me use my own domain (posteo.de does not).

They also implement DANE, MTA-STS, TLS-RPT. They use [https://en.wikipedia.org/wiki/Open- Xchange](https://en.wikipedia.org/wiki/Open-Xchange) which allows for things like Guard (temporary mailbox for recipients, they click a link write their message into the browser). They also have a @secure.mailbox.org alias that will force TLS, (not opportunistic).

Additionally they have inbox encryption which will encrypt anything you get in your inbox save in sent (via imap) with a sieve filter that uses your public key. You can keep the private one in your key ring locally.

ProtonMail has their bridge which is supposed to allow full body search (something which is kind of hard when you pgp crypt all your email), however I have read varying responses on the stability of that.

Tutanota has no API access, you must use their email client, web browser. Protonmail has contacts, but no calendars yet so you might still want to use something like [https://www.etesync.com](https://www.etesync.com) or [https://radicale.org](https://radicale.org) on your own server.

</comment></comment></comment><comment><USER5> Google messed up my email account when they were changing something in Google for Domains (this was a free Google for Domains account, when those were free, and a personal domain, I was an earlyish adopter) and were merging Google For Domain and GMail accounts. There was no support on being locked from the account. Fortunately, having bounced around hotmail etc two decades ago, I had the foresight to register my own personal domain name, and had a backup of mails.

Have your own domain name.

Don't use your registrar to host your email, or website (interesting and wise advice from Dreamhost, a similar amount of time ago).

Running a mailserver is a pain, to be frank, unless you're in it to learn. A paid 3rd party with an SLA (Service Level Agreement) is a good option, and perhaps a privacy slant too. Perhaps Protonmail?

</comment><comment><USER6> I've in the process of switching from gmail to mailfence. What I like about mailfence is it has email, contacts, calendar, and cloud storage, plus it's secure. I'm only beginning the process so I can't yet say they're great, but I'd check them out. Or protonmail, fastmail, and others are good, too.

</comment><comment><USER7> For email, you can use Cloudron from the DO marketplace.

DO opens up port 25 by raising a support ticket.

<comment><USER3> > _I tried creating my own mail server with DigitalOcean but they didn 't open > port 25 for me_

> _DO opens up port 25 by raising a support ticket._

Should also note many of the DO IPs are on blacklists so you'll probably have issues with mail being delivered if you do that.

</comment></comment><comment><AUTHOR> Everyone, do you know which server provider allows opening port 25?

</comment><comment><USER8> Sad story :(</comment>


System Admin WebApp - Newbie Requesting Advice - <AUTHOR>

I made a Django web app for work that records local administrators on Windows and Mac OS X machines and reports them to the security team.
I think this would be a great tool for other system administrators.
Is anyone interested?
I built a quick survey on wufoo here http://asnark.wufoo.com/forms/local-administrator-reporting-survey/. Please fill it out if you are interested.
I welcome any comments or questions. Thanks. <comment><AUTHOR> clickable link: [http://asnark.wufoo.com/forms/local-administrator- reporting-...](http://asnark.wufoo.com/forms/local-administrator-reporting- survey/)</comment>


How to eat an elephant: Planning software development - <AUTHOR> http://devcomsystems.com.au/2013/01/how-to-eat-an-elephant-planning-software-development/?preview=true&preview_id=383&preview_nonce=08329801d9

<comment><USER2> [http://devcomsystems.com.au/2013/01/how-to-eat-an- elephant-p...](http://devcomsystems.com.au/2013/01/how-to-eat-an-elephant- planning-software-development/)

<comment><AUTHOR> Whoops! Thanks for the link labpdx.

</comment></comment><comment><USER3> "You do not have permission to preview drafts"</comment>


Free E-book: Distributed Systems Observability - <AUTHOR> http://distributed-systems-observability-ebook.humio.com/ <comment><USER2> > "Monitoring of yore might have been the preserve of operations engineers, > but observability isn't purely an operational concern"

Yore ?

Observability is much more than logs, traces and metrics. Yet we consider the 3 pillars of observability to be logs, traces and metrics only. No wonder why the concept of observability tends to be equated with monitoring alone

<comment><USER3> Can you provide an example of a 4th?</comment></comment>


Sketch goes subscription-based - <AUTHOR> https://blog.sketchapp.com/versioning-licensing-and-sketch-4-0-8ad98783e9ba#.4kidz0od0 <comment><USER2> Is this a subscription?

No. Once your license has expired you can still use the app for as long as you want. We will not force you to pay again to use it. You don't have to renew your license if you don't want to.

<comment><USER3> I'd say it's a subscription when you have to have the latest version if you're working with other designers.

</comment></comment><comment><USER4> How many submissions of this story are we going to get?

[https://news.ycombinator.com/item?id=11861188](https://news.ycombinator.com/item?id=11861188)

[https://news.ycombinator.com/item?id=11861255](https://news.ycombinator.com/item?id=11861255)

[https://news.ycombinator.com/item?id=11861273](https://news.ycombinator.com/item?id=11861273)

[https://news.ycombinator.com/item?id=11861329](https://news.ycombinator.com/item?id=11861329)

[https://news.ycombinator.com/item?id=11861473](https://news.ycombinator.com/item?id=11861473)

[https://news.ycombinator.com/item?id=11861553](https://news.ycombinator.com/item?id=11861553) (1 comment)

[https://news.ycombinator.com/item?id=11861656](https://news.ycombinator.com/item?id=11861656) (2 comments)

[https://news.ycombinator.com/item?id=11862255](https://news.ycombinator.com/item?id=11862255)

[https://news.ycombinator.com/item?id=11862687](https://news.ycombinator.com/item?id=11862687)

[https://news.ycombinator.com/item?id=11863487](https://news.ycombinator.com/item?id=11863487)

[https://news.ycombinator.com/item?id=11864219](https://news.ycombinator.com/item?id=11864219) (this one)

<comment><USER5> Everyone is submitting the extra tracking (e.g. #.8gco2nehu)

That might have helped with this story. It seems like there was a lot of interest but you know how things move fast on HN...

<comment><AUTHOR> Yep. @dang, thought the dupe detector was robust against this sort of thing?

</comment></comment></comment><comment><USER6> This software is moving too fast imo. Our designer uses it and routinely I can't open files because they changed the file format. Also, didn't they just recently move away from the App Store?

<comment><USER7> Consider switching to the affinity suite [1]. I use it for all my personal projects, and professionally if I can get my coworkers/clients to use it too, which I strongly advise. It's full-featured and much cheaper than Adobe software, and IMO comes with less upgrade headaches than sketch.

[1] [https://affinity.serif.com/en- us/designer/](https://affinity.serif.com/en-us/designer/)

<comment><USER8> I am kicking myself a little for just buying Sketch right before this. I was considering Affinity too.

</comment></comment></comment><comment><USER9> No it isn't, you buy the software as before and get updates free for a year. This is not a subscription.</comment>


Oxygen creation from collisions of carbon dioxide with surfaces - <AUTHOR> https://www.nature.com/articles/s41467-019-10342-6 <comment><USER2> Can someone explain what is strongly-bent CO2 configuration?

<comment><USER3> As shown in Figure 3 (inset IV) and described in the paragraph above. CO2 ordinarily is linearly-bonded to O's on either side of the carbon (another view: [https://en.wikipedia.org/wiki/Carbon_dioxide);](https://en.wikipedia.org/wiki/Carbon_dioxide\);) this a temporary change in the bonding angles.

"the rebounding CO2 undergoes substantial intramolecular rearrangement ... CO2 acquires a triangular configuration with nearly equal bond lengths..." called a strongly bent CO2 intermediate.

Interesting idea; hope something comes of it.</comment></comment>