And you see no problem with that?
213 karma · joined May 23, 2020
And you see no problem with that?
« Daniil, a university student in St Petersburg, said he reluctantly downloaded Max shortly before the start of the academic year after being told students would be denied access to university buildings or dormitories without a QR code generated through the app. »
Interestingly, it wasn't designed to deal with case, but to select whether to resolve symbolic links:
$ cd /tmp
$ mkdir a
$ ln -s a b
$ cd b
$ pwd && pwd -P
/tmp/b
/tmp/aIt's good enough for undergraduate teaching. In C, you can easily explain the relation between a struct definition and its layout in memory. It's much more difficult in Caml (what's the relation between an algebraic datatype and its layout in memory?) or Java (which introduces pointers that you never asked for).
We (University of Paris-Cité) are teaching Java in first year, then C and Caml in second year, with seemingly good results.
Thanks. I've had a quick look, and it looks like it's a drop-in replacement for fail2ban (it claims to parse fail2ban's configuration files unchanged), except that it doesn't require a Python runtime.
I haven't tried it, since I'm currently happy with sshguard. I'm keeping the link handy in case I find I need more features than what sshguard provides.
He got elected with 49.8% of the popular vote, even though he had already been in power and people knew reasonably well what his policies would be.
Thanks. I've replaced fail2ban with sshguard on one machine, we'll see how it goes.
Just to clarify: OsmAnd has more features, CoMaps and Organic Maps are much faster.
(Aside: I'm using CoMaps myself. The main missing features are tracking (I use OpenTracks for that) and public transportation (I use a website for that). End of aside.)
That's exactly what Galene does when a user requests a file transfer.
> with network topologies those days, it will most likely require a relay between the two
We perform NAT traversal by using the server to punch holes in both NATs. Only if that fails (due to a symmetric NAT or to an overly restrictive firewall) do we fall back to relaying through the server.
For a demo, go to <https://galene.org:8443/group/public/hn/>. Login twice in two different browser tabs (leave the password field empty). Click on the username of your partner, and choose Send file.
No. The right analogy is an image of the Reichstag with Nazi banners.
Such as?
The encoding itself is locale-independent. Some algorithms (rendering, casing, hyphenation etc.) depend on the locale.
This is unlike the older paradigm, where the encoding itself was dependent on the locale, making things like copy-paste between applications running in different locales problematic.
Traditionally, character's under Unix were encoded in a locale-specific manner: ISO 8859-1 in Western Europe, ISO 8859-2 in Eastern Europe, EUC-JP in Japan, etc. In the 1990s, there was a major push to get XFree86 (the ancestor of X.Org) to switch to locale-independent UTF-8, lead mainly by Markus Kuhn and Bruno Haible.
The link is to Markus Kuhn's web page, which appears to describe the UTF_8 software available around 1998 or so.
I'd be interested in learning more, but the links you provide are just advertising copy. Could you please provide links to actual technical articles on your conclusions?
Here's a recent sample, paraphrased for brevity:
Them: this is broken.
Me: no, it's not broken.
Them (a few days later): "I think I must not have tried all the combinations", followed with two pages of transcripts.
Me: "I've just checked the code, and you're right [...] I'm extremely sorry I wasted your time."
Them: "Heh, it's all good. I'm am chuffed you're taking the time to give thoughtful responses with me"
You really want hardware decoding on mobile, otherwise you end up with 40 minutes battery life. Fortunately, for typical videoconference resolutions, VP8 and H.264 are just fine. AV1 is nice to have, though, due to excellent support for synthetic content (screen sharing), and for scalable video coding (a much more elegant solution than simulcast, IMHO).
In the world I live in, the general plan is to stick to VP8 and H.264 for the time being, and to skip to AV1 when it's universally available on mobile. I haven't seen any features of AV2 which would justify waiting for it.
You must have a very large family. To saturate 500Mbit/s, you'd need around 30 family members all streaming at the same time.
That's not how I remember it. By the time we got data cassettes, we knew very well that floppies were the future.
There's also the fact that when you write open-source code, you're writing for a friendly audience. I've often found myself writing the code, letting it rest for a few hours, then rewriting it so that it is easier to read. Sometimes, the code gets substantially rewritten before I push.
There's no cooling period when you write code during your 9-5 job: it works, it has the required test coverage, ship it and move on to the next task.
They added some obfuscated code to Windows 3.1 that made it refuse to run on DR-DOS. https://en.wikipedia.org/wiki/AARD_code
Google are obeying the letter of the law, while openly violating its spirit. Perhaps it'll be possible to attack them in court, but it will take years, and by that time they'll have found another trick.
Extremely common at major universities and research centres. CTSS, ITS, TENEX, Multics, Unix and even VM/370 were all alternate operating at some point.
> Other than OS2, alternate OSs for other systems were rather rare,
You weren't there, were you? A lot of people replaced MS-DOS with DR-DOS before Microsoft deliberately broke it with Windows. A little later, a number of people were running Unix System V on their PCs, to the extent that there was a regular column about Unix in Byte.
100BASE-TX uses just two pairs (lanes), one for sending and one for receiving. 1000BASE-T uses all four pairs, for both sending and receiving. Therefore, a 100BASE-TX interface that's only receiving needs to power up one pair. A 1000BASE-T interface needs to power all four pairs all the time.
I recall reading about some extensions that allow switching off some of the pairs some of the time ("Green Ethernet"), but I think that they require support on both sides of the link, and I'm not sure if they are widely deployed.
> This is a mailing list.
The way I understand it, the layering is different. In X.400, multicasting was a feature of the protocol. An SMTP mailing list, on the other hand, is an endpoint that terminates a protocol transaction, and then initiates one transaction for each final recipient.
I guess it boils down to where it is preferable to have the extra complexity: the ITU-T protocols invariably prefer to put it inside the network, while the Internet protocols prefer to put it at the endpoints. The SMTP protocol is simple, and therefore the mailing list software needs to be complex.