throwawayish

Pretty much the only people that are working towards splitting the community are people like you, who spread FUD and sprinkle snide, bitter and wrong remarks across threads.

I couldn't agree more. This transition and their release management in general has been handled excellently for years. Anyone complaining here is quite literally whining.

The GIL is encoded into practically every C API of the interpreter. It's not going away in CPython, and at the very least any Python implementation supporting CPython extensions will have a global lock for calls into extensions.

And even if (there were patches for removing the GIL already around in the 90s): All of the approaches and patches shown so far significantly degraded single-threaded performance, which matters to way more applications than the GIL, which typically is not a significant limit to using multiple cores/processors.

"Teh GIL" is a very, very overblown issue, and is -- I don't want to be condescending here, but well -- usually brought up by people that have little experience writing software that makes effective use of multiple-many cores.

When I started with Python - around 2011ish - Python 2.7 on Windows (with Qt 4) was a reasonable choice. Not much later almost everything I did was on Python 3. No regrets, no looking back, and no missed opportunities.

Yeah no.

I know that there are domains that are mostly on Python 2, and of course you'll always have legacy / unmaintained things lying around. But "zeee majoritie is Python 2.7!!1111" does not become true by some people chanting it over and over again. The simple fact that frameworks and libraries are moving away from Python 2 already proves that the majority does, in fact, not use Python 2. Otherwise maintainers would also be in an approximate majority to block/veto such changes.

While the admin code is kinda messy it's still easy to extend and customize. I'd be somewhat surprised if you could make something that dynamic and not be at least a bit messy.

I myself and also other people I know have written quite some domain-specific applications almost entirely within the Django admin, which are as a result: secure, fast and easy to use, which in some cases are not just a bit better than the existing commercial tooling in these domains.

> the lot of them are closed source

That's wrong. See OpenSPARC, where you can get the Verilog code for the T1 and T2 (Niagara-based) processors. (IIRC this was only one year after their commercial release).

SPARC in general is perhaps not a bad example, since the ISA is open and royalty-free and there are actually independent implementations (well, today only Fujitsu and ofc. Oracle).

It's quite interesting to see RISC raising again after it died rather harshly in the late 90s -- were literally every year a major manufacturer announced the end of an architecture -- and early 2000s (and remained dead rather firmly throughout the 2000s).

Uh, well I guess...? But generally speaking IC fabbing doesn't happen in the "couple hundreds". If you really want that, you'd be looking at MPW (multi project wafers), were a bunch of designs are slapped on a single mask to spread yield and reduce per-party costs. (It pretty much works like PCB group manufacturing - a bunch of designs is slapped together 'til the maximum size of the fab, and then that is produced a couple times, e-tested, cut and bad pieces discarded. Everyone gets a couple copies of their design.)

Today it's a bit better, since eg. GF can (in theory) offer recent nodes (eg 22 nm and smaller), which wasn't something you could get ten years ago (back then that'd be 65 nm - most low-volume and custom stuff has been iirc 130 or 180 nm).

> Consider Linux versus Windows. My suspicion is that Microsoft has spent more money on Windows dev than has ever been spent on Linux dev.

I'm not so sure about that, if we only consider the kernel (everything else would be a lame comparison). Linux likely has had many more paid devs than the NT kernel for the last 10-15 years, if not more.

> This is a fallacy

I also don't think this is a fallacy. Yes, of course a large company has a big head and spending is generally much less directed and efficient than in smaller companies (big news). But, lots of money also tends to pay great talents.

> that I see repeated about the quality of open products all the time.

... and I didn't mention quality anywhere.

As for open source: Software has near zero initial cost, iterations are extremely fast compared to anything manufactured and software engineering is an abundant skill. Hardware has high initial costs, high manufacturing costs, iterations take a lot of time and HW design encompasses quite some areas with a much smaller pool of people being able to do it.

Also, a massive company like Intel which sucks up talent all the time from the hiring pool has the resources to evaluate multiple avenues of optimization at the same time, pick what looks best, and iterate (which, pretty much, is what Intel has been doing ever since Sandy Bridge). Another example here would be Intel developing P4, a massive and staggering failure comparable to the PowerPC970 debacle (just bigger) -- and then pulling the Core arch out of the hat (which originates, guess what, from a different engineering team in a whole different branch of Intel -- again, resources!).

What I do expect here is that some companies might think they can influence an arch early on by diverting resources to it, to maybe save some money in the future (by not paying ARM anymore and other synergetic effects I mentioned above), and perhaps in the hope of getting a product that outperforms ARM/the competition in some metric(s).

(Also we have seen in the past in quite some instances that CPU design is a very delicate art and even pouring massive monies into it might actually not get you very far - see AIM/PowerPC [although it was quite successful in some niches] - or, on the other hand, that radically new architectures that might theoretically be better don't succeed, because you don't get the fab access, or tooling access, or software, see eg. Transputer and many related examples)

Copyright (c) 2016- Facebook, Inc (Adam Paszke)

Copyright (c) 2014- Facebook, Inc (Soumith Chintala)

Copyright (c) 2011-2014 Idiap Research Institute (Ronan Collobert)

Copyright (c) 2012-2014 Deepmind Technologies (Koray Kavukcuoglu)

Copyright (c) 2011-2012 NEC Laboratories America (Koray Kavukcuoglu)

Copyright (c) 2011-2013 NYU (Clement Farabet)

Copyright (c) 2006-2010 NEC Laboratories America (Ronan Collobert, Leon Bottou, Iain Melvin, Jason Weston)

Copyright (c) 2006 Idiap Research Institute (Samy Bengio)

Copyright (c) 2001-2004 Idiap Research Institute (Ronan Collobert, Samy Bengio, Johnny Mariethoz)

Notably absent is the otherwise Facebook-typical PATENTS license thing. Which I see as a good sign.

Also, it doesn't look like this has happened just now? PRs in the repo go back a couple months and the repo has 100+ contributors.

It's interesting to work alone on a big-ish project with no one telling you what to do and not having to explain anything to anyone. It easily feels ten-times more productive (in terms of accomplishment), but then again it won't have a business case and one doesn't get paid, either.

I think I'm least productive in open source (again, in terms of felt accomplishment), because if one isn't the sole maintainer (like above), then it's a pretty safe bet that few changes take less than a certain baseline (eg. 1 hour) -- someone always has a nitpick, CI always takes it's sweet time, oh, did we discuss yet in which branches we wanna merge this? Ah, please avoid puns in documentation and comments. Do we want this? Can you write this differently, like ...? Did you manually test this or that scenario ...?

(Now this also has advantages in terms of stability, quality and consistency -- but it's also obviously far, far less efficient)

On the clock it's more like "Meh, change that and that, otherwise it's good, so merge it after these changes and tell ops to put it in prod"

It's completely unreasonable to expect some underdog architecture to get anywhere close to the big ones, which have pured dozens of billions of dollars into research over decades to optimize their designs, tooling and fabrication.

A reasonable expectation is to get some low-end-ish CPUs out that might be on the same level (in terms of efficiency) than older, not really optimised ARM designs.

The biggest incentive RISC-V can offer is less legacy bullshit (like AArch64) and the fact that you don't have to pair royalties to ARM. Perhaps better standardisation of peripherals compared to ARM, so less time/money spent on integration, BSPs and stuff like that.

(And even then: Looking at recent POWER one can see that they can outperform related Intel offerings, while being drastically less efficient.)

> The Java world tends to be pretty conservative and slow-moving compared to newer, trendier languages.

newer, trendier languages like Python, Ruby or C++? ;)

> Aluminum is the most common material for heatsinks,

Aluminium is the most common material for heatsink fins. The cold plate is almost always (nickel-plated) copper.

The external signalling power used by computers is completely neglible compared to the heat output. Computers and IT equipment in general are essentially ideal heat converters.

Ah, you're the guy why newer LGA2011 caps come with a yellow-red warning sticker about "NOT USING ANY FORCE"? ;)

At the time water-based heatpipes weren't used for coolers, which made all coolers much, much less efficient. Today practically every CPU cooler uses 2-8 heatpipes and that's what makes all the difference. (Well that and not using top-blowers anymore).

git and blockchains have in common that they both use cryptography.

So you might have as well said "Signal".

Safe shell coding tip #10451: Variables containing directories always have to end in a slash, and paths may never be built using variables and slashes.

> Think about it as an SSD manufacturer - what's the easiest way to wipe a drive?

That's not the reason why encryption is always on. Flash endurance is; encrypting the data before FEC means that it will have a random distribution, which avoids pathological worst cases with certain workloads. You could also use a different (cheaper) scrambler than AES (like CPUs do [1]), but since encryption is a marketable feature...

[1] Which are also switching to using AES and offering memory encryption in current mainstream architectures.

Some institutes at some universities have access to the NT source code for academic purposes. (Google "Windows Research Kernel" -- supposedly some academic entities have more access).

Java, like NT, was originally UCS-2 and moved to UTF-16 when it became clear that UCS-2 won't suffice. APIs that operate on units (anything involving "char"s [the type], CharSequences and so on) are legacy and, when used, are almost certainly used incorrectly. Note that newer APIs on String also use the word "char", but the type "int", these are actually operating on code points and not CUs, ie. these APIs are correct.

(Note that java.lang.Character is a char, so wrong. I think there is no CodePoint type or similar that wraps int.)

String indexing is pretty rare. Most of them are s[0] or s[:n], where you don't need an index.

Typically this is found when parsing something, eg.

    if line[0] == '#':
      # skip comment lines
      continue

Or

    prefixes = {...}
    for line in lines:
        prefix, remainder = line[:4], line[4:]
        if prefix not in prefixes:
            raise ValueError('Invalid prefix ' + prefix)
        parsed = prefixes[prefix](remainder)

> You deal with strings as bytes (opaque data) (edit2: didn't really mean bytes here. see child comments) more often than strings as text in systems programming, basically.

That's true in some sense [1] for unix-ish OSes, but doesn't hold on other operating systems.

[1] Even on unix-ish OSes it's pretty obvious that filenames are supposed to be encoded in something and aren't just uint8_t*. There's just no one telling you what that encoding is, so normally it's guessed (eg. $LANG). For filesystems that actually have a defined encoding (eg. NTFS\Win32, JFS, HFS+, APFS and the whole bunch of "non-unix OS FS") these are re-coded by the filesystem driver in the unix-ish OS. Eg. ntfs-3g transcodes filenames to UTF-8; cifs takes a "iocharset" option; and we of course have convmv(1).

The idea that "file names and generally everything in the OS is a bunch of bytes" is pretty much only shared by unix-ish systems.

> error_msg would be easy to pick up for translation, rather than have to do some cludgy import as _ and _("Internal error!"). Hm, now that I'm writing this here, I guess it's still not a type you'd want to operate differently on than just plain unicode strings.

This is maybe ok for very simple cases, but doesn't work as soon as you need context (in Python this is either done by extra _ parameters or through special comments) or pluralization.

Central European languages can get more or less by with Latin-1, although even there many characters are already missing, iirc French, Czech, Dutch and Finnish. Special characters of many regional dialects are missing as well.

FWIW (more or less proper) Unicode support seems to be pretty much an implicit, hard requirement today for almost anything facing users.

Favourite colors don't follow a random distribution. IIRC with blue and green you already have two thirds of the population.

This is Debian. They don't just change the display system in a point release.

    if invalid(input):
      log.warning('UberForm field wrong: ' + input)

(And many subtle variations thereof)

An entirely different but similar issue is logs. If you aggregate logs in a simple, unstructed text file, then it becomes pretty easy to add faked log lines, or, if they're viewed in the terminal plain-and-easy, embed VT control characters in log lines that can hide other log lines. And with creative use of Unicode one can also often confuse readers.