This is the C explanation perspective, but a similar thing could happen in Python, if you write `s[0]` instead of `s`, perhaps due to a refactoring that changes an array of keys to a single key. This is because Python does not distinguish characters from strings. (Not an indictment of Python; just another proposal for how this could happen, and I would say it is more likely to use Python than C in some hacked-up signing script.)
Well, my example is C++, it relies on function overloading existing for, for example, to_string(uint8_t[]) and to_string(uint8_t) separately, which means this error would come down to overloading instead of catching the type error.
Just saying, because C++ is very popular everywhere in this "kind" of company, if you catch my drift.
Fortran had arrays since the beginning, but it wasn't really for "array-based programming" except in a trivial sense, since expressions could not produce arrays. APL is the language that invented first-class arrays, and is far more advanced at it than most of its successors, particularly including NumPy.
Modern Fortran has pretty serviceable support for array programming.
I'm surprised to hear that about laptops. When I first switched to Linux in 2003, laptops were supposedly a somewhat iffy thing. When I got my first laptop in 2007, I had to do a bit of research, but ultimately ended up with a ThinkPad where everything worked fine, modulo the need for proprietary graphics drivers as was common at the time. Since then, I don't think I've ever stressed about whether a laptop would be properly supported. I am easily believe that maybe some things are a little better in Windows (maybe automatic firmware update, or the CPU governor), but which laptops are "not very well supported" by Linux these days?
I never trust people saying "it works well". Heck, even Canonical lies in their certification program, since they may test with custom distros that they may not release (yeah, it's this crazy).
My last machine, according to reviewers, worked "well" on Linux. After I purchased it, I've found that the battery lasts half of what it lasts in Windows. And other stuff.
No doubt that there are 100% compatible machines (Thinkpads, typically), but again, it limits choice.
In the mid to 2000's at IBM, many of us developers and even quite a few regular business people in marketing ran Desktop Linux on Thinkpads, it worked extremely well. I assume they still do.
Yes. The initial problem was ACPI tables in the BIOSes. They were wrong for benign (Windows doesn't care about them much, so the manufacturer was not aware that they are important), or not-so-benign (break them to break Linux compatibility on cheaper devices) reasons. Suspend and Hibernate work pretty flawlessly on higher end devices (i.e. Thinkpads, Pro/Elitebooks, Compaq NX series, etc.) for longer since these machines were designed as OS agnostic and had flawless BIOSes in terms of implementation w.r.t. consumer devices.
Remember, Halloween documents' opening salvo was the idea of extending ACPI so that Linux becomes unbootable on PC hardware.
Hibernation is the same deal. You also need to have a swap file/partition slightly larger than your RAM, since it's dumped to SWAP during hibernation.
So, why don't you come over here? We have cookies.
I don't know what "well" means, but I suspend my laptop whenever I move it around, travel, etc. I used hibernation a lot many years ago, where it worked as perfectly as I would expect.
It is easier to verify that there are no problems on Apple hardware. Windows and Linux run the same for me, you need good hardware to run well. Usabiltity and taste is a different question.
I used Bitlbee until not that many earth rotations ago - it's an IRC daemon that provides bridging of various other chat protocols. It worked way better than you would expect, especially back in the day when you could use XMPP to connect to the various proprietary chat services.
I didn't stop using it until I stopped caring about those chat services.
I think there is a deep conceptual unlock: concurrency is about semantics, whilst parallelism is an operational property. I use this distinction a lot in my own work. Concurrent programming primitives are inherently non-deterministic (and usually about handling non-deterministic events), on top of which we must then establish some kind of properties (sometimes determinism to some extent). Many interesting parallel operations are however completely deterministic, and the fact that they are parallel is a property of their assigned cost model (and hopefully implementation, in practice).
I agree that this distinction is hardly universal, but it seems to be growing increasingly established, and I think it is worth fighting for it.
I don't like the essential characteristic of concurrency being nondeterminism. its really that multiple processes are running concurrently. if we don't have serializing operations, we have arbitrary execution order. but if we do then we can introduce the necessary determinism while still being (largely) concurrent in evaluation. and if those logically concurrent processes are physically concurrent then we have parallelism. so the first is necessary but not sufficient for the latter.
so I find saying that we have one or the other to pretty misleading.
Im not saying arrival order isn't a key consequence of concurrency in many cases, it's just not the same as concurrency itself. I guess the point for me is that when we're programming or when we're using models, we define the partial ordering. so if an event arrives from outside and causes a message to be put in the queue, the read of that event by another thread is still after the external event.
so our job is really to kind of look at all the possible topological sorts of that 'after' ordering, and ensure that they are all correct, and if not, add additional edges by using locks or whatever mechanism.
kind of more interested are techniques like mvcc and crdt, which make _any_ causal ordering of events (topo sort) result in a meaningful answer.
but if you look at classical simd for example, we have concurrency (and parallelism) without additional constraints, because the threads are strongly synchronized at the hardware level.
Clarification for non-Danes: this post is not entirely accurate. Not all Master's courses in Denmark have oral examinations, and many courses before the Master's level (including elementary school) have oral exams. It is unrelated to the academic level, and instead related to the academic discipline and the size of the course. The latter is in my experience the main constraint, as oral exams are difficult to scale. They usually take 20-30 minutes per student, and if you have a course with 200 students, well, you're in for a long time.
The oral exam format described is also somewhat unusual, in my experience. It is usually the case that there is one internal examiner and one external examiner in the room. More than that would be ruinously expensive. The format varies; usually it's a combination of a short presentation and questions asked by the examiner. Drawing a random topic is very common.
Source: I am a university teacher in Denmark who teaches master-level courses without oral exams, and I have been an examiner for many oral exams at university level.
There was an interesting talk I heard a while ago about the scalability of oral exams vs written. They did quite a bit of study of typical exam preparation and marking times and the cross over point where oral exams were actually taking longer than written exams was surprisingly high, around 180 students or so. To be fair though I think they considered 15 min oral exams, but the gist is that in the scalability argument people tend to forget to account for marking and exam design time appropriately.
The problem is not the total time commitment, but the flexibility of when that time can be spent. The time expenditure for a written exam (writing the exam set, testing it, correcting submissions, having a grading meeting) can be spread over many weeks, with plenty of room to move things around to take care of other responsibilities, and easy tolerance for delays. Oral exams have to be scheduled in a dense block because students are only available during designated exam weeks, and any delays have cascading effects.
I run my personal website (and a bunch of other websites and services) off a somewhat more expensive but still reasonable VPS (I think 20€ at TransIP - it's so little that I forgot). Load is basically nil most of the time anyway. I think the bot problem is not so bad for personal websites.
Comic Chat is a piece of Internet history, but I remember that it was somewhat reviled when I first started being active on IRC. This was around 2002, so it was probably due to some cultural memory rather than anyone having actually used it in years.
The issue, as I remember it, is that Comic Chat extended the IRC protocol with support for explicitly indicating the appearance and emoting of your comic character, rather than relying entirely on contextual cues. This was essentially done by adding some nonsense string to every message, which presumably could be decoded by other Comic Chat users, but read like spammy noise to everyone else. I know it did that, because I remember downloading Comic Chat to check it out, but I forget whether it was the default or not.
On the IRC servers I managed I always set up an automatic kick when one of these messages was sent anywhere on the servers. It would ban after 3 kicks, which was a necessary change from the immediate ban as legitimate users got curious sometimes and installed Comic Chat.
It was fun messing with these folks, though, since they were often oblivious to IRC and internet culture in general. Or they were just completely tech illiterate, but somehow ended up starting Comic Chat, and somehow ended up on our obscure servers.
I was one of these hapless Comic Chat users. Luckily someone gently nudged me toward a real IRC client lol. I was an absolute IRC fiend for years after that.
Comic Chat inspired me to make multiplayer games with IRC as the lobby server. But I specifically did not do what Microsoft did and send the metadata through the public channel, because I too had gone through the public ridicule of using Comic Chat. Instead, I used DMs between users to perform the signaling (which would then open a socket to create a direct TCP connection between the players).
It was pretty easy to do. Had to have been, because I was a pretty terrible programmer at the time.
How far we’ve sunk! Back then we got irritated by attempts to use open systems, nowadays a system like this would use a closed proprietary system from day one.
I have to imagine the answer was either "dedicated MSCC servers and EEE" depending on your level of cynicism or "it was just a tech demo that escaped".
MS encroaching on existing protocol and behaviors then making a mess is well established patterns, Outlook defaulting to answering to e-mail on top is one of these atrocities
