dhess

Does Bolle sell those upgrades? Got a URL?

TPC OLTP.

Hackworth | ONSITE (but WFH for now) | FULLTIME | London | https://www.hackworthltd.uk/

Hackworth Ltd is a well-financed, bootstrapped, private limited company based in London. Our purpose is to make programming relevant to children of all backgrounds. We're currently in the prototyping and research phase for our first product: a novel, interactive learning environment for programming, rooted in functional programming principles, with a particular focus on structure editing and the visualization of program execution.

We're currently looking for a front-end web developer. To apply for this role, you should have at least 2 years' worth of experience designing web-based user interfaces, and be proficient in one or more of JavaScript, PureScript, or TypeScript. Please see here for the full job posting:

https://www.hackworthltd.uk/jobs/20201001/

This role is on-site in London, though we're indefinitely in work-from-home mode due to the COVID-19 pandemic. You must be eligible to work in the UK, as unfortunately, we can't sponsor visas to work in the UK at this time.

We hope to hear from you! If you have any questions, email careers@hackworthltd.com and it'll come directly to me.

Hackworth | ONSITE (but WFH for now) | FULLTIME | London | https://www.hackworthltd.uk/

Hackworth Ltd is a well-financed, bootstrapped, private limited company based in London. Our purpose is to make programming relevant to children of all backgrounds. We're currently in the prototyping and research phase for our first product: a novel, interactive learning environment for programming, rooted in functional programming principles, with a particular focus on structure editing and the visualization of program execution.

We're currently hiring for 2 full time roles. These roles are on-site in London, though we're indefinitely in work-from-home mode due to the COVID-19 pandemic. You must be eligible to work in the UK, as unfortunately, we can't sponsor visas to work in the UK at this time.

* UX designer: https://www.hackworthltd.uk/jobs/20200901/

* Front-end web developer: https://www.hackworthltd.uk/jobs/20201001/

We hope to hear from you! If you have any questions, email careers@hackworthltd.com and it'll come directly to me.

Hackworth | UX designer | ONSITE (but WFH for now) | FULLTIME | London | https://www.hackworthltd.uk/

Hackworth Ltd is a well-financed, bootstrapped, private limited company based in London. We're hiring a full time user experience (UX) designer in London. This is an on-site role, though we're indefinitely in work-from-home mode due to the COVID-19 pandemic. You must be eligible to work in the UK, as unfortunately, we can't sponsor visas to work in the UK at this time.

Our purpose is to make programming relevant to children of all backgrounds. In this role, you'll lead the UX effort for our first product: a novel, interactive learning environment for programming, rooted in functional programming principles, with a particular focus on the visualization of program execution.

You should have a master's degree in HCI, or equivalent practical experience in a related field. You should also have experience with quantitative and qualitative methods of research design. Knowledge of programming languages is a plus, but not required (you won't be expected to write code).

For more about this particular role, please see the posting at https://www.hackworthltd.uk/jobs/20200901/

We hope to hear from you! If you have any questions, email careers@hackworthltd.com and it'll come directly to me.

I spent most of my career in Silicon Valley, where employers routinely take the position that they own every thought their employees have, and every work they create. That position, legally enforceable or otherwise, has always rankled me.

I've recently moved to the UK to start a tech business here (https://www.hackworthltd.uk), and now that I'm on the other side of the table, I very much wanted to create a personal projects policy that was as employee-friendly as possible, while still protecting the interests of the business. I hired a UK IP lawyer to help me draft an acceptable policy, and I'm happy to share that with you, if it helps.

The intellectual property section of our employment contract is mostly standard boilerplate, as I understand it, except that it refers to our personal projects policy, which is contained in our staff handbook. I've copied the relevant sections of both and put them here:

https://gist.github.com/dhess/21b7d2d72c4f9d4e0cdd8004385ef7...

Please feel free to use it as a reference in future negotiations with your employer(s).

Comments from others are also welcome! I'm open to any suggestions for how it could be improved.

Hackworth | R&D software developer | Onsite | London | https://www.hackworthltd.uk/

Hackworth Ltd is a well-financed, bootstrapped, private limited company based in London. We're hiring a full time R&D Haskell developer in London. This is an on-site role, at our office in Shoreditch.

Our purpose is to make programming relevant to the interests of children of all backgrounds. Our first step toward that goal is to develop programming languages and tools that are designed for learning about computation. We're currently in research mode, so this will be a fun, low-pressure, educational experience for the first 9-12 months. Prepare to do lots of prototyping and learning.

You should have at least 2 years' experience programming in Haskell for industry or research, and you must be eligible to work in the UK.

For more about this particular role, please see the posting at https://www.hackworthltd.uk/jobs/20200204/

Hope to hear from you! If you have any questions, email careers@hackworthltd.com and it'll come directly to me.

No. Watch this:

https://youtu.be/mp8chvACVBk

That's a great idea. I've run my own mail servers since 1999. I'd happily join a union of independent mail operators with the purpose of lobbying Google, Microsoft, and Yahoo to treat us as first-class citizens.

I've tried all kinds of WiFi gear over the past 5 years -- Apple, UniFi, Aruba Instant -- and all of them have been unsatisfactory in one way or another:

* Most of my client devices are from Apple, and I easily got the best WiFi performance overall with 802.11ac-capable Airport Extremes, which is impressive given how relatively cheap they are. However, I'd like multiple SSIDs, and Apple gear can't do that (the guest network support doesn't count). Regardless, Apple is out of the game, so this isn't a long-term solution.

* The UniFi gear had terrible 802.11ac performance, even when my devices were in the same room as the WAP. At the time, I was using first-gen 802.11ac hardware from UniFi, so it's somewhat understandable, but the poor performance combined with 2 of the units failing within the first 6 months didn't leave a good impression.

* The Aruba Instant WAPs were reliable and got good performance (though not as good as the Apple WAPs), but I'm not a fan of their licensing. Without a support contract, it was possible to hunt down the latest firmware updates, but they didn't make it easy.

I recently bought a PC Engines APU3C4 with a mini-PCIe WiFi card and a couple of Chaohang antennas [1], and I'm contemplating build my own WAP. This would give me all of the configurability and tweaking that I want, and I could deploy it as just another piece of my personal little devops pipeline.

However, I don't know much about the RF side of things. I'm aware there's a lot of black magic involved, but it's not clear to me how much performance and/or range I'm going to lose by piecing together COTS stuff versus a professionally-engineered solution from Ubiquiti et al. If anyone who's reading has built their own WAPs, I'd love to hear from you.

[1] https://www.amazon.com/gp/product/B01E29566W

Both will give your VPS a "home" IPv6 address, but if you also expect to receive an IPv6 prefix/subnet, DO only gives you a /125 per VPS (8 IPs). I moved my VPN nodes to Vultr for that reason; they give you a /112 (65K IPs) per VPS.

Neither DO nor Vultr actually routes the assigned prefix to your VPS, so you have to run something like ndppd [1] to answer NDP queries for IPs in the IPv6 prefix you've been assigned if you want the local router to send your VPS any traffic on those addresses.

[1] https://github.com/DanielAdolfsson/ndppd

Nix can already encompass stack/cabal, cargo, pip, gem, and npm in a single system. I never need to use 'npm install', 'cabal install' or virtualenv/pip anymore. Nix does it all for me. So if your concern is that you have too many package management systems already, take another look at Nix, as it can probably replace them all.

(Except for the App Store... no way to manage App Store apps with Nix.)

I switched from brew to Nix about a year ago. Nix is, like many powerful tools, difficult to learn, but rewards the effort down the line.

Nix is best thought of as a way of building software, not simply as a package manager, though you can use it only for that if you want (and that is probably the best way to become acquainted with it). So while you can certainly use Nix instead of brew, that is just scratching the surface of what Nix can do for you, if you are in the business of software development or devops. In my view, that is the primary reason to make the switch, because Nix is so much more than just a package manager.

Among the benefits of Nix are:

* Reproducible builds - If you and I use the same Nix expression to build something, each on a different machine, you can be sure that you and I will each produce the same build artifacts (binary executable, library, docs, etc.). [Note - on Macs this is occasionally not true due to "impurities" that creep in from the base OS, but the Nix folks are working to make this a thing of the past on Macs, as well -- see "sandboxed" builds.]

* Distributed builds - Let's say I have a laptop and a desktop. I can configure my laptop to use my desktop as a remote builder for faster builds. This even works for building, say, Linux packages from a Mac. Just tell Nix on your Mac about any Linux hosts where you are also running Nix, and if you ask the Mac to build a Linux package, it will farm the work out to the Linux remote builders.

* "Channels" - You can choose from one of several Nix "channels," where a channel is a subset of the full Nix package set. Some channels are pinned to a specific official release -- 17.03, 17.09, etc. Think of these like you think of Debian or Ubuntu releases. These receive only minor backported version upgrades and security fixes. If you want something more up-to-date, you can run one of the "unstable" channels. These are updated more frequently and may break from time to time; however, the continuous integration server (see below) can give you some guarantees, namely that the packages in these channels will at least build correctly. The unstable channels are equivalent to what some Linux distributions call "rolling releases." (And, if you want, you can just build against the git repo and control your package versions that way, eschewing channels altogether.)

* A community package cache - one of the advantages of reproducible builds is that build artifacts can be cached and used by everyone. The Nix project runs a continuous integration server that builds packages for x86_64, i686, aarch64, and macOS. As long as stay on one of the channels (see above), there is a good chance that your package will already have been built by the CI server, so that your machine can just download the end product and doesn't have to build it. (If you are a Haskell developer like me, this can be a godsend! The CI server builds a pretty reasonable subset of Hackage.)

* Easy package overrides and additions - this and the excellent Haskell support were the main reasons I originally switched from brew to Nix. Perhaps brew has a better story for this in 2018, but overriding packages and adding new ones to the brew package set was not particularly easy when I used it. In my time, it usually involved maintaining your own brew fork in Git. With Nix, it's a simple matter of importing an "overlay" into your Nix configuration. The overlay can modify existing packages, or add whole new ones, with just a few lines of configuration and a Nix expression (equivalent to a brew "recipe," or whatever they call it). Also, I can easily share my overlays with others; just publish it on GitHub and tell someone to import a single file from that repo into their Nix config, and they will see the same package overlays as I do. Finally, overlays are composable by design, so you can combine them from multiple sources to create a single package set tailored to your needs.

I could go on, but I'll stop there. Oh, except to mention that cross-compiling support is coming very soon, so that you will be able to build packages for, say, armv7l-linux on your very fast x86_64-linux build server. If you do embedded development like I do, this is huge. When this work is finished, I believe that only Debian/Ubuntu will have a similarly compelling cross-compiling story (minus all the other benefits that Nix brings, of course).

Interestingly, though my initial motivation for the switch from brew to Nix was to use it as a package manager, one year on that is easily the least of the benefits I've derived from learning it. It has completely changed the way I build and deploy software and Linux hosts. (I have not mentioned here NixOps, because it is not relevant to Macs, but if you do any kind of Linux deployments and you are using Nix, you will probably want to at least take a look at NixOps.)

Anyway, highly recommended.

Yes, me too. My name, not my address, similar comment.

The original submission title ("Majority of economists against net neutrality") is at best a distortion of the cited survey's results. Even without considering the confidence-weighted outcome, 44% of those polled "agree" or "strongly agree" that allowing content companies to pay more to ISPs for prioritized traffic is a good idea, while 56% are either "uncertain," "disagree," or have no opinion. (The confidence-weighted outcome is only 1% different.)

Also, this survey appears to have been done in 2014.

Yes. Comcast Business, SF.

No need to apologize. It works great for my needs and it was easy enough just to hack your hack :)

FYI, there's a WIP PR for Vultr backend support in NixOps.

https://github.com/NixOS/nixops/pull/634

I cherry-picked this into my local NixOps repo and have been using it for several weeks to deploy to Vultr servers with no issues, except one -- the author has hard-wired an assumption that you're using Btrfs for your root filesystem. I didn't want that so I simply replaced that hard-wired assumption with ext4 in my personal branch. Now everything is working great.

Yes, please do provide some citations. This is interesting stuff.

Hear, hear. I've tried on multiple occasions to use Edisons in my projects, and the tooling is awful. Intel's communication with the hobbyist community is even worse. It's hard to understand how there isn't an Intel-supported Ubuntu or Debian distribution for Edison.

I have fried one or two, but it was my own fault each time. (Do not connect the +5v from the barrel connector to the GPIO pins!)

I use a BB Black in an outdoor location and it runs 24/7 with no hitches, and has been for months. It's in San Francisco and it's inside a control box, so not the most extreme conditions, but it has survived all the recent wet weather and hot days last summer with aplomb.

edit: I have flashed the firmware numerous times on several boards and have never had an issue.

Yes. Robert Nelson maintains the kernel and various accoutrements for the BeagleBone Line, and he is fantastic.

Start here:

http://elinux.org/Beagleboard:BeagleBoneBlack_Debian

See https://en.wikipedia.org/wiki/Peering.

Grandparent's point is that, depending on where you're trying to send or receive traffic, you might be limited by Linode's (or the hosting data center's) peering agreements, rather than the 1gbps NIC speed.

nftables "mark" would behave like pf "tag" if you can filter a packet further downstream based on the value of the mark. (It looks like the mark functionality is also present in iptables.)

If people are using marks for policy-based firewalls a la tag in pf, it doesn't look like a particularly common practice, based on a quick Google search. Anyway, it's a start. Thanks for the pointer.

I also happily use OpenBSD on my firewall. Every year or two I'm tempted by pfSense, and each time I'm scared away by the thought of running PHP on my firewall, and other security issues as outlined so well in this thread by lima [1].

The one thing I most envy is pfSense's multi-WAN failover support. I have a USB LTE modem plugged into my firewall. OpenBSD can see the device, I can use it as my default gateway for Internet access, etc. However, I only want to use it when my primary ISP is down, for some definition of "down" (e.g., major packet loss). I want the firewall to detect this condition; switch to the LTE modem as the egress interface/default route; reload a different pf.conf, tuned for the LTE modem; restart ospfd, ospf6d, and rtadvd; and then watch the primary interface until it recovers, at which point the firewall reverts to its primary config and restarts the routing daemons again.

It appears that pfSense supports this scenario out-of-the-box, via "gateway groups" and multi-level tiers [2]. OpenBSD does not -- its multi-WAN support is intended for load-balancing, and/or assumes a carrier-grade routing environment using BGP or equivalent. People have asked for help with this scenario on the OpenBSD mailing lists, and the answer is usually, "this is what ifstated is for, write a script"; which is fine, I guess, but it would be nice if everyone who wanted to do this didn't have to write their own bespoke solution.

Speaking of which, does anybody here do this with their OpenBSD firewall and has a nice, clean, well-documented example of how it works? I once trawled through the pfSense source code to see how they do it, and their implementation was all wrapped up in a bunch of PHP. Yuck!

[1] https://news.ycombinator.com/item?id=13615724

[2] https://doc.pfsense.org/index.php/Multi-WAN#Failover

Does nftables support packet tagging/policy filtering ala pf's "tag" keyword [1]? It's so nice to tag a packet as "trusted" once it has passed an input filter, and then just pass trusted packets on outbound interfaces based solely on the tag.

For example, on my OpenBSD firewall I can write the following simple rules to restrict outbound Internet access to a specific set of IP addresses or networks:

  # internal_if is the LAN-facing interface; isp_if is the ISP-facing interface, i.e., the Internet.
  match in log on internal_if from <internet_allowed_networks> tag OUTBOUND
  pass in  log quick on internal_if tagged OUTBOUND
  ...
  pass out log on isp_if inet tagged OUTBOUND nat-to (isp_if) static-port

The tags are sticky, so that you can apply multiple tags to packets and sort through the tags later in the pipeline.

If nftables supports something like this, I'll probably make the switch, as I prefer Linux in every other way to OpenBSD.

[1] https://www.openbsd.org/faq/pf/tagging.html

Last Friday, my OpenBSD firewall, which runs on a SYS-5018A-FTN4, mysteriously crashed. I chalked it up to an alpha particle or something and rebooted. About 12 hours later, it failed again. This time I did some more digging. On the console was the following message:

  NMI ... going to debugger
  Stopped at    acpicpu_idle+0x22d:     nop
  ddb{0}>

I googled it and found one similar report on the OpenBSD misc mailing list from September 2016 [1]. Interestingly, the person who reported the bug was running the same Supermicro board as I was. The report didn't get anywhere other than a vague suggestion that it might be heat related. These boxes run very cool and I didn't think that was likely. I thought it might be a RAM issue and that it was probably just a coincidence that the other person had the same hardware as I, but now I'm inclined to think that both of us have experienced the issue described in TFA.

Seems like I'll be looking for new firewall hardware.

[1] https://www.mail-archive.com/misc@openbsd.org/msg149348.html

Can you provide a link to an iTunes Music Store release that is available in ALAC format? I am not aware of any.

As of December 2016, I believe you are, generally speaking, incorrect. iCloud data is encrypted in transit and at rest, but only iCloud Keychain is encrypted "in such a way that Apple cannot read or access" it.[1] For all other data stored in iCloud, Apple both provides and retains access to the encryption keys. Note that this includes iCloud backups you make of your iMessages; however, if you do not back up your iMessage content to iCloud, then technically speaking your iMessages are not part of your iCloud footprint and Apple does not have access to that content.[ibid]

Apple's law enforcement guidelines[2] provide more detail about what Apple effectively has access to and can/will provide upon presentation of a warrant.

(As of iOS 9.3 and macOS 10.11.4, it appears that notes that you explicitly password-protect in the Notes app are also encrypted with a user-supplied key to which Apple has no access. They don't explicitly mention this functionality in [1] or [2], but they do imply that this is the case in [3].)

There have been rumblings [4] since the San Bernardino case that Apple is considering providing what you describe, so that users can provide their own encryption keys for their iCloud content and backups, such that Apple no longer has access to the plaintext. However, Apple has not implemented this functionality yet, and I haven't heard anything about it since the FBI dropped its case against Apple in this matter.

[1] http://www.apple.com/privacy/approach-to-privacy/

[2] https://www.apple.com/legal/privacy/law-enforcement-guidelin...

[3] https://support.apple.com/en-us/HT205794#forgot_password

[4] [paywall] http://www.wsj.com/articles/in-beefing-up-icloud-security-ap...

I also returned my 13" MBP with Touch Bar. I also experienced issues with WiFi after wake (would not reconnect to my network), but my chief reason for returning it was the abysmal 4-5 hour battery life under light browsing usage.

In its place, I purchased a 2016 13" MBP with the 15W CPU and no Touch Bar. Oddly, its battery has about 11% more capacity than the Touch Bar model [1]. In their battery tests, Ars Technica reported that it lasts about 3 hours longer than the Touch Bar model with 28W CPU [2][3]. Here's hoping I see similar results.

[1] http://www.apple.com/macbook-pro/specs/

[2] https://cdn.arstechnica.net/wp-content/uploads/2016/11/touch...

[3] http://arstechnica.com/video/2016/11/the-2016-13-and-15-inch...