This is a great article, I hope the people that want to continue using Eudora can find a way to fund its development.
Attachment to software like this seems a little weird to me, but I guess if someone decided to take away mutt I would be quite up happy. Thankfully that isn’t possible without open source software.
So, it’s working really well but the complex stacks in Linux are breaking a lot. Especially on hardware stuff. I’m curious if anyone in NetBSD or OpenBSD camps plans to try to get those working on it. That might be a better experience esp for console users.
There is a FreeBSD effort to port to POWER9, I think one developer has also received a TALOS II.
Hopefully the market will expand and we will see lower prices. I am all for diversity, but damn $7000 for any machine is a lot of money.
That’s a good thing. A high-quality, high-performance UNIX on POWER9. Especially for high-security since a contender for most secure UNIX is CheriBSD which is FreeBSD on capability-secure, MIPS-based CPU. One might use TALOS II to develop for it. More importantly, in long term such security enhancements like CHERI could get merged into an OpenPOWER core that becomes a future TALOS workstation. A significant drop in performance from checks might not hurt if the starting point is what a POWER9 or up can do. ;)
I think the price tag might put a damper on it for both devs and users. Not much demand, so why sink the development time?
Some people (outside the “NetBSD or OpenBSD camps”, too…) spend their time on such things because they are able to and they value diversity (POWER9 is the most interesting part in this case, at least for me).
I think that this was true for Apple’s PPC hardware supports your point. It cost a bit extra with small market share. A lot less software was developed for it. However, the groups that stayed on it after Apple ditched PPC made a lot of software work on it. So, it’s possible a niche effort could make these usable.
Im not sure what the overlap is between those kind of devs and people that can drop almost ten grand on a machine.
Spencer Dawkins published an early draft at IETF 101 “Path Aware Networking: A Bestiary of Roads Not Taken” to try and capture some of the mistakes protocol designers have made over the years. It is probably worth a read and worth following as more accounts are added.
https://tools.ietf.org/html/draft-dawkins-panrg-what-not-to-do-00
Lots of maybes still:
So far:
Upcoming:
I would love to go to 35C3, but there are too many uncertainties that far in the future to lay down any plans.
I use FreeBSD as my desktop at work.
Really it depends on your work load, I write network code and write stuff in latex. Almost everything I do can be done from a terminal, if you can give me a large enough terminal and mosh then I could probably do 90% of my work.
Very occasionally (2-3 hours a month) I have to do video calls with skype/webex that requires using a macbook. Sometimes I also use the mac to make diagrams in omnigraffle, but that might be once a year.
I don’t think this is a new idea. The real issues are single sided deployment and breaking assumptions middleboxes on the network make. RFC1693 was my first hit on google I imagine this space has been explored.
Of course, I’m ignoring fiddly details like segment boundaries, interactions between this strategy and flow- and congestion-control, and so on. It’d take a lot of work to really do this!
To experiment with this you could use SCTP with partial reliability. I am not sure if you could still use a stream socket in the same way you would use a TCP stream socket, it might be interesting to play with.
Work: Implementing this ietf draft on top of this ieft draft on FreeBSD. If I am really lucky I won’t have to deal with any bureaucracy this week.
!Work: Probably too much.
The GPD Pocket has a whole raft of devices connected to i2c, for some reason I can’t figure out ig4 is unable to use the bus. I need to ask for help on a mailing list, but need to find some time to focus my question. I have a review in to support the gpio controller (which the fan is connected to), if there is progress on that it will become the top task. The back light is controlled by pwm, I have written most of a driver for that, but I can’t get acpi to probe the hid it should be on. That needs more time to look at.
Sick of reading datasheets and linux sources trying to track down the ig4 issues I spent this weekend working on bringing up the mt7610u usb wireless driver. I need to figure out why the usb stack doesn’t like my usb descriptors before I can continue.
work: adding support for UDP Options to FreeBSD while trying not to mangle the network code too much.
!work: More work on drivers for my GPD Pocket. I figured out the ACPI junk to get most of the power related stuff attaching to i2c buses described there, but I have hit a snag with ig4 where it times out transfers. While avoiding looking at that I found OpenBSD has a driver for the gpio(chvgpio) so I am porting that to FreeBSD now.
I am using a tiny usb dongle right now, tear downs have shown there is no way to replace the internal card. The wireless is the same as the pi3(though pci) and there is an effort right now to add support for the colocation controller on the soc. It might actually be a card that sees support in the next year or two.
The corresponding Linux brcmfmac driver is ISC licensed.
Work: Looks like I am getting ahead of the reporting and can get back to work on crazy changes in the FreeBSD network stack.
!Work: Writing drivers to handle the power stuff on this crazy little laptop I have. Amazing how drivers spring up when datasheets are available.
Looks like a GPD Pocket. What keyboard is that?
It is an MIT-layout Planck. Parts are regularly available and MassDrop occasionally runs group buys for kits. I am waiting for the current group buy to ship, though it has been delayed ~10 weeks because they neglected to plan for FCC Part 15 certification.
It looks like it could be just the thing for an on-call support engineer - you could toss it into a small bag and take it out to the pub, restaurant or whatever. You can do that with a MacBook, but they’re really that light or small, and you really don’t want to forget your bag with one of those in it.
Great stuff in this
We are no longer processing router advertisements in the kernel. We are no longer generating privacy addresses in the kernel. Remove knob and always do neighbor unreachable detection.
Why were RAs ever processed in the kernel? It doesn’t seem useful to me. I know some people at BIGROUTER that think they will miss messages that arrive before the host is up and are adding more and more RA stuff into Linux to account for this. I don’t think messages that arrive before you are up are something worth worrying about.
Implement counter clockwise rotation for rasops consoles. Rotate if width < height.
Seems like common sense to be, those with a portrait display probably expect to do some config anyway. I have a laptop with a rotated panel that could do something like this out of the box.
This is an awesome setup to read about, I am glad it was posted.
I spend a good deal of my time working at the command line. In fact I rarely use any other graphical applications than a web browser and an editor. I’ve found that it’s often much quicker to do the task at hand on the command line than to use an interface which was primarily designed with mouse users in mind.
How many lobsters could this paragraph apply to?
GPG is so simple. You and someone else generate some keys. You exchange them safely somehow validating each other. Then, just write stuff in a text file with boring name, seal it with GPG, and send the resulting file over some medium (eg email). Ignore all other functionality since it’s complicated or requires trusting third parties. Just do one-to-one with text files. The UI problems could even be scripted away or programmed as an extension into an editor.
The result: you get protection the NSA couldn’t break that works on diverse hardware and software (reduces subversion risk). Most people aren’t worried about NSA. Usually a weaker threat. So, something NSA had hard time with should be extra safe for them.
The problem is that simple, relatively easy to use work flow isn’t the one advocated. Instead gpg nerds go on about the web of trust and key signing parties and tell people off for doing minor things wrong.
Is there a gpg work flow documented somewhere that is as easy to use as signal and a verified key? I would love to use that.
Not that easy yet but simple enough to be made easy. Start with this:
http://irtfweb.ifa.hawaii.edu/~lockhart/gpg/
Here’s the major steps:
Generating key, exporting one’s own public key, importing others’ public keys, encrypting a file for a specific user whose key is in database, or decrypting a file from the user. The front end just needs to be able to handle those actions. The whole thing might be reduced to an open or seal command in a plugin for a text editor for day to day use with extra commands in the menu for generate, import, export, or backup db. Alternatively, a modification of GPG itself to straight-up delete all the other crap or at least the interfaces to it importing the result into a GUI app with better interface.
The trouble is that all the boring, trivial UI stuff never gets done. Partly, I suspect, because no-one is ever paid to do it.
the guy developing gpg gets money, more than a lot of free software projects can dream of: https://en.wikipedia.org/wiki/Werner_Koch
i guess with that money a somewhat usable gui should be possible.
Remember that he got so little for so long he was thinking of quiting. Then, some emergency money was thrown at him largely without conditions after the press about that. So, it’s not the same as a person just making stuff with money coming in regularly with expectations by users for great UX. He can do it but is not incentivized to do it.
Even if he was, he’s not a UX expert - that’s something that requires a bit of knowledge, planning, research, and likely a big refactor afterwards.
Good point. Most programmers, esp for crypto stuff, aren’t UX experts. Hell, we’ve been seeing “Why Johnny Can’t Use My App” papers from them for some time now.
Of course, he could hire a UX designer, (or firm) but that’s quite a bit of money. Considering GPG’s status though, someone might be willing to do it pro bono.
usability is a well known reason why people don’t use it. why don’t take a part of the money and pay another developer to build and maintain a nice gui? if the wikipedia article is still correct, the donations of facebook and stripe equal $100000/y. even if it would be reduced to 50k due to taxes, it is still a nice amount of cash in germany: “In Germany, the average household net adjusted disposable income per capita is USD 31 925” http://www.oecdbetterlifeindex.org/topics/income/
Good point. Alternatively, like with my experience, the programmers just hack together a solution that will work for them and their local audience. Then, don’t put in further effort to develop it into more general solution for wide audience. I didn’t even publish mine since they were very, very specific to my use case.
keybase has done quite a decent job making a more user-friendly interface to GPG (CLI and GUI).
Are they still encouraging users to hand over their private keys to them? That puts it in the bad sector as far as I’m concerned; if I’m going to be trusting a central organisation I might as well just use Facebook messenger.
Good point. I loved the Keybase concept when I last looked into it. Since this topic keeps coming up, I might try out their client in the near future to see if I can offer something better than GPG cheat sheet haha.
What an awesome article, really gives me some ideas about what to do with the DEC-PRO I picked up a couple of months ago.
Does anyone know of articles that go into writing microcode for the Alto?
I am presenting a poster at EuCNC in the really Northern Oulu Finland. If any lobsters are in town message me and we can meet up for a beer.
I am trying to get some work done while on the road, I have managed to finish analysis of a tcp modification for a colleague. I am hoping to do some work on a wifi driver now the tcp stuff is out of the way.
Quite a lot of data to deal with, some thoughts:
The pay disparity between the US and EU(and UK) for now is very large. If US developers are paying less than 50% of their salaries on health care then they are coming out a head. There is something to be said for statutory leave (vacation days), but the choice to earn 2x (or apparently 4x) what I do is quite enticing.
Binning 20+ years experience together generates uninteresting plots.
If US developers are paying less than 50% of their salaries on health care then they are coming out a head.
Also, in the US, most have to own a car. Our public transit sucks. And housing near tech areas is super expensive. Still, the difference is stark.
You also have to keep in mind that living expenses in Germany, France, and most of the UK (with the exception of London) are much much lower than the Bay Area.
LibTLS looks really interesting, all the work I am doing currently is datagram based and with no DTLS support I don’t get the chance to play with it. I understand their decision not to incorporate code that doesn’t have anything driving it, that is a great way to avoid bloat and bitrot.
Kudos to the whole team, I am really happy there are people making the internet better by building core tools.
This week I am finishing up slides for my two FOSDEM talks(hopefully) and filling reports for the EU ahead of a review. I need to do some prep for a hackathon next week in there too.
I made some real progress in bringing up wifi on a MediaTek MT76x0 driver at the weekend. This week I am hoping to figure out the firmware differences so I can start loading that correctly.
This week(and next and last) I am trying to finish the slides for my two coming FOSDEM talks. On top of that I am building out a demo, working on a paper and getting ready for a hackathon and meeting the week before FOSDEM.
Outside of work I am working on more shameless self promotion systems for my blog. I am poking at the atheros wireless drivers in my laptop. I am working with adrian@ to get spectral scanning working on the ar9460 in my c720.
This was a great article and well worth the read, ports of unix to other platforms aren’t so common and in depth write ups are even more rare. It is a shame that the font on the page is so small (fixed by inspect element in firefox) and that the figures are not in line with the text.
I know that FreeBSD has been ported to two hardware architectures quite recently (riscv and aarch64), it would been nice if their authors could write up similar articles.
A friend through the local hackerspace always tells me his story about using 386BSD. He was mercilessly flamed by Bill Jolitz and driven away for 368BSD (and he didn’t want to waste his precious disk on a TCP/IP stack he wouldn’t use). Later he got an apology and explanation from Lynne.