lambda

This is full-on crank territory here.

In fact, for at least one of our components, we've already done this. We had something that solved the same problem for a couple of different permutations of software versions and platforms. The person who had originally written it had used separate repos, with common code copied and pasted between them, and later on we merged the repos together and factored out the common code so that could be shared. So we already have at least one repo which has 4 root commits, I believe.

Actually, I just checked and it has 7 root commits. I'd forgotten that we had also had similar problems that needed to be solved for some other software, and had some interns who had done those in separate repos as well, which also eventually got merged in to share all of the common code:

  $ git log --max-parents=0 --pretty="format:%h %cd %s" --date=short
  666c0bf 2012-07-09 Initial tree.
  528ca3a 2012-06-12 first commit
  50f1b18 2012-06-12 first commit
  86d66e0 2011-11-17 initial
  76a7789 2011-03-21 initial commit
  58f7afc 2010-05-20 initial
  deb50b7 2009-10-29 initial commit

I picked up the habit again just because it's nice to have that warm, tasty beverage to start the day, and decaf just isn't the same. As long as you keep it to one in the morning and maybe one in the early afternoon, it's fine.

Providing macOS gives a developer and designer platform for iOS. That is really important for them. So Metal being available on macOS is important for that reason. But it's also important in that the Mac platform is still important, just not nearly as important as iOS.

OpenGL doesn't really have much of a future. Everyone is moving towards the next generation frameworks. It just happens that there was a lot of uncertainty about whether OpenGL could adapt or whether there would be a successor, and during that time Apple decided to invest in developing Metal. It wasn't until a couple of years later than Vulkan was released.

In the meantime, Apple has built up quite a lot of tooling around Metal.

And it's not like it's that difficult to write cross platform apps that target the Mac. If you write against major engines, they will already have support for the different backends. If you are writing your own software, you can still target OpenGL, or you can target Vulkan and use MoltenVK to run it on macOS.

And for the next several years, people writing portable software are going to have to either just target OpenGL, for compatibility with older graphics cards, or maintain at least two backends, OpenGL and Vulkan. Given that lots of games target DirectX first, and consider any of the cross-platform frameworks a porting effort, Apple probably doesn't consider it a big loss to add one more platform that needs to be ported to.

What's going to wind up happening is more software like ANGLE (https://github.com/google/angle), MoltenVK (https://github.com/KhronosGroup/MoltenVK), and gfx-rs (https://github.com/gfx-rs/gfx and https://github.com/gfx-rs/portability, see http://gfx-rs.github.io/2018/04/09/vulkan-portability.html for details) for providing one set of abstractions on top of several different backends.

The Unlicense sometimes causes issues with software being accepted into larger collections. CC0 is much more thoroughly drafted, and more widely accepted.

You notice that Apple supported OpenGL while they were making most of their money from desktop and laptop sales; but once iOS became so profitable, they decided to go their own way and start pushing Metal.

Lock in, or at least getting people to do more iOS first development (helped by lower profits on app store sales on Android, Android fragmentation, etc), helps Apple out a lot. You get the first version of apps and games, or more polished versions of apps and games, on iOS this way.

This is quite inconvenient for someone just wanting to do a little bit of experimentation before committing.

For instance, I was interested in experimenting with AltiVec on POWER for the Rust bug bounty. I wanted to get an idea of the scope of the problem, see how things work in C and C++, do a little bit of quick microbenchmarking in C and C++ to see how it compares to SSE.

If it turns out that it was something I was interested in pursuing further, I might try to work with the Rust project to apply for this kind of access officially for a CI system for the Power architecture. But that's a lot of trouble to go through if I just want to do some quick experimentation before deciding on whether the scope of the project is worth it.

You don't use github just for git.

You use it for issue tracking, pull requests and code review, CI hooks, wiki, github pages, kanban boards, bot integration, and so on.

That's all stuff that locks you in to Github, and is non-trivial to migrate to another provider.

The issue is the ability to interact in any way with cross site resources which contain any kind of potentially sensitive information. This leads to things like clickjacking attacks, CSRF, information leaks like this, and so on.

The things that could be done to fix it:

1. Don't allow any kind of cross-site embedding (yeah, this isn't going to happen) 2. Treat any kind of cross-site embedding like private browsing mode; don't ever send any credentials along with it 3. Don't allow the embedding site to interact in any way with embedded content. Treat it like an entirely separate, opaque layer above everything else, not subject to layering anything over it

Of course, I don't think any of these are actually going to happen, because they'd break too much. But otherwise, it's going to be a game of whack-a-mole with information leaks, new kinds of clickjacking and CSRF, and so on.

Persistent memory is something that Intel has been working on for at least 5 years (https://github.com/pmem), and given that that's the public face of the software side of it, they were likely starting to develop the hardware even earlier.

How so? Point to the quote?

Although, for RAM and storage you can purchase that separately at cheaper prices.

I just tried to sign up for IBM's cloud, to see if I could use the limited free trial or $200 credit to try out one of the bare-metal systems.

Nope. The limited free trial only seems to apply to a few of their SaaS offerings; and the $200 credit also doesn't apply to their "infrastructure services" like VMs, bare metals servers, storage, etc.

Additionally, it looks like you need to get manual approval for you account to be able to use the VMs; even once I added my credit card info, they tell me my account needs to be reviewed by someone before I can actually rent server time.

On AWS or GCS, you just sign up and spin up VMs. I've used that many times for quick compat testing against different operating systems, some quick extra CPU cycles, deploying test servers, and so on.

But on IBM's cloud, you need someone to actually manually approve your account before you can do anything but use their SaaS offerings.

They really don't seem to want to attract people casually trying things out.

edit: after a bit, they did approve my account for infrastructure access. But the bare-metal POWER servers can't be rented by the hour, only by the month, and they start at $1000 per month. Still not really helpful for casual exploration. They also have such wonderful usability features as requiring you to allow popups in order to configure and order servers or VMs.

Oh, and I guess I shouldn't have called it a mainframe operating system; that's z/OS. IBM i is their minicomputer operating system.

That is starting to approach the price point where it's worth it if you want to tinker, but with something that is a lot closer to a real machine than a $250 embedded board.

I tried taking a look for cloud services that offer POWER machines, but couldn't find anything that I could just sign up for and try for relatively cheap. There are a couple of universities that have free POWER clusters that you can request access to, but for tinkering I'd actually rather be able to pay for what I'd need rather than having to manually request access.

Do you have references to cloud services that would allow you to easily get access to POWER9 systems by the hour? IBM's own cloud services only seem to offer bare-metal POWER8 servers by the month; as far as I can tell (from their fairly confusing pricing page and docs), all of their virtual servers or hourly servers are Intel.

It's all POWER though, and I seem to be seeing more of it around recently. I had thought that it was going to just keep on shrinking into a more niche market once Macs, Xboxes, and Playstations stopped using POWER/PowerPC processors, and Intel was dominating in the cloud, but it seems like they're actually investing again in trying to get out of the relatively small niche they're in now.

Maybe it's just my perception though; I happen to have noticed POWER related things happening in a couple of different areas recently. I haven't been following it very closely.

Do you develop for AIX and IBM i for work and have access to hardware and inspiration to do this for that reason? If not, how did you wind up picking this as a hobbyist endeavor?

I looked into doing this briefly, and a couple blockers were that I couldn't find any easy cloud services offering POWER that I could use for testing, the cheapest dev system I could find, the Talos II Development System, is itself $5000 once you add RAM and storage (https://www.raptorcs.com/content/TL2DS1/intro.html, they do have a cheaper system available in pre-order: https://www.raptorcs.com/content/TL1BC1/intro.html), and the C intrinsics that they offer work with special overloaded functions with a vector type extension to C, making it a lot harder to use the approach of just offering wrappers for basic intrinsics and then working on higher-level support on top of that.

Looks like gnzlbg put more effort into it, but ran into similar issues: https://github.com/rust-lang/rust/issues/42743#issuecomment-...

Can't you just urinate first, flush, and then defecate?

Hmm, I just switched to flycheck. Is it worth checking out this new flymake?

But I can buy the argument that just having a single auto-enforced rule improves consistency and that has greater benefits than the somewhat vague distinction that is not enforced.

The reason I always fight with people who want to increase line length is that they generally want to increase it to 100. Which is just a bit too big to fit two columns comfortably side by side at a reasonable size on a laptop screen, or three columns side by side on a wide desktop screen, which is how I generally set up my editors.

I'm always frustrated with codebases that use a 100 character standard, since I'm always running into lines that wrap, but when I use type annotations, 80 characters causes too many function signatures to have to wrap.

This leads to the following difference between the PEP 8 recommendation and Black:

PEP 8 accepts both of these:

  ham[lower+offset : upper+offset]
  ham[lower + offset : upper + offset]

  ham[lower + offset : upper + offset]

  slice[a.b : c.d]

After typing this all out, I think that it might be the case that the bigger difference is actually in how binary operators are treated. It looks like Black always puts whitespace around binary operators, which contradicts PEP 8's recommendation that you are allowed to vary spacing around binary operators to make precedence clear.

Since Black does allow for leaving in extraneous parentheses to make precedence clear, I wonder why it doesn't allow varying the space around binary operators as well? Of course, it should enforce that the spacing actually does match the precedence, and that the spacing is consistent within an expression. That would allow the following examples which PEP 8 lists as "Yes":

  x = x*2 - 1
  hypot2 = x*x + y*y
  c = (a+b) * (a-b)

  x = x * 2 - 1
  hypot2 = x * x + y * y
  c = (a + b) * (a - b)

Somehow, the field of psychiatry doesn't seem to actually act on it.

Or they do, since they prescribe drugs which are designed to cross the blood-brain barrier, but even when they decide to prescribe drugs, they don't actually do any kind of blood tests to determine which drugs are likely to be effective.

They prescribe drugs based on simply you talking about your own symptoms, or observing your symptoms, and then just trying things until they find something that works or that you report works. They don't even seem to use any kind of formal testing of cognitive functionality to determine what effects the drugs are having; they just rely on purely subjective chats with the patient.

If you are claiming they are backed by USD, and you are creating them out of thin air, then that's a scam.

Other coins are only valued based on how the market values them. There is no fraud there; you are not claiming that you will redeem them for something else, they just represent themselves and are valued based on how useful people find that particular kind of cryptocurrency, plus hype.

MtGox was also a scam by the end, since they were trading on their exchange bitcoins and USD that they didn't actually have for people to cash out.

Registration fees and taxes are frequently based on weight; and tolls are frequently based on number of axles.

But the relationship between weight or axles and fees is generally linear, while the actual wear and tear on roads is quartic (to the power of 4) in the weight per axle, times the number of axles. If taxes and fees were properly proportional, there would be a much bigger difference in price between a motorcycle and 1 ton pickup truck, let alone an 18 wheeler.

> Do you really want to have to log every mile driven, and submit it to the IRS?

You can use odometer readings that you collect at annual inspections. I realize that not every state does this, but every state I have ever lived in does; you have an annual vehicle safety and emissions inspection, and at that point they can check your odometer too and include that in the calculation.

You could also use the current automated toll collection systems, which are based on transponder or license plate for those who don't have transponders, for highways and congestion charges for cities, if you want to be able to charge different rates in different areas, and just subtract those numbers from the odometer readings afterwards.

Metering EV charging separately does't really solve the problem. Gas taxes are not in proportion to actual maintenance costs of the roads, and are currently a fixed amount, not tied to the price of gas or inflation, so they don't cover the full costs. If you just applied the same kinds of laws to EV charging, you'd be left with the same kinds of problems.

By not charging proportional to road wear and tear, there is an effective subsidy of those who drive larger vehicles, and in particular commercial cargo transport on the highways, by those who drive smaller vehicles. If you were to change the way vehicles were taxed, the larger vehicles would pay more of the burden, which would mean they might switch to alternatives like train transport, or moving production closer to consumption, or the like.

A similar problem exists in cities and on busy highways used by commuters, where congestion is a substantial externality. There it's the square footage of vehicle footprint that makes the biggest difference.

There are no more toll booths in the state of Massachusetts.

If you travel on a toll road in Massachusetts, your car will be tracked either by E-ZPass transponder, if you opt in to that system (at a substantial discount), or via photographing the license plate and sending you a bill in the mail.

Also, pretty much everyone I know, even the most privacy conscious, carry a tracking device in their pockets at all times. I think that rms may be the only person I've met who I know does not.