Sure. But that's one less level of indirection than if you also had to jump around to get the reference to the object in the first place.
1,147 karma · joined October 22, 2019
Python sequences are defined as "support[ing] efficient element access using integer indices" [1]. Python lists are sequences and thus must support random access. In practice that means the implementation is a (dynamically resizing) array allocated contiguously. That means spatial locality is relevant.
If the list type were defined simply as an iterable collection, with no requirement of constant-time random access, the definition would be abstract enough that an implementation might end up being something else than a contiguous array. But if you define the type so that it supports constant-time random access [2], you pretty much end up with cache-friendly sequential access as well.
If you don't define the list type as supporting random access, you also sacrifice asymptotic algorithmic efficiency for lookups by index. Any language that cares about efficiency at all separates collections that support efficient random access from those that don't. (For example, Python has lists and dicts/sets for different access patterns. The Java standard library has separate types for contiguous arrays/lists, hashtable-backed collections and tree-backed collections because the three have different algorithmic efficiencies for different access patterns. In practice it leads to different properties in terms of cache-friendliness as well.)
[1] https://docs.python.org/3/glossary.html#term-sequence
[2] As usual, the Python documentation is a bit vague on the details. It doesn't really say random access has to be constant-time, only that it has to be "efficient". So you might be able to have a non-constant time implementation such as an indexable skiplist while arguing that it's efficient, but you'd have to go out of your way to do that.
Well, this. And at that point we'd likely be facing the same situation in just about every other information-intensive field as well. Yet it doesn't seem like anybody has any idea how to prepare students (or anybody else) for that kind of a future.
It seems absurd to give up on learning and understanding things ourselves because of a hypothetical future for which nobody has a better plan anyway.
I think the PCI bus probably also typically ran at some fraction of the front-side bus. The common FSB frequencies around those times were 66 or 100 MHz which gave a standard ~33 MHz PCI bus frequency with a multiplier of 1/2 or 1/3. FSB frequencies that weren't close to a multiple of 33 MHz might have caused trouble with some PCI cards. Might have depended on how the motherboard or chipset handled the bus frequencies, too.
Of course the PCI bus should probably always run at 33 MHz but I think I saw it being modified with the FSB speed at least on some motherboards.
Might be a case of covering their asses in the context of services they provide for search suggestions etc. Those are not mere programs users run on their own devices, and they rather make use of services run by Mozilla, which probably leads to their lawyers seeing the need for legally covering Mozilla ass.
A less charitable interpretation is that they actually want to introduce terms for using the software itself, in a way that conflicts with the no-nonsense "no restrictions on use" approach of open source, and thus ignoring open source principles in preference for covering their asses against hypothetical risks, while somehow still trying to look like open source.
In any case I agree the blog post or the update don't make anything better. I don't think the post says anything substantial about the terms of use or their introduction. It doesn't, in concrete terms, clarify anything about the seeming conflict between the introduction of terms of use and the commonly accepted definition of open source (which includes no restrictions on use). The post rather seems like a classic case of trying to make things better with nice-sounding words rather than owning up and actually clarifying any ambiguity.
So either they're saying your use of Firefox, regardless of whether you want to use Mozilla services, must also follow the same acceptable use policy that your use of their services would, or it's a massively ambiguous way of saying your use of Firefox in combination with actual Mozilla services must comply with the policy.
If it's the former, their terms of use would be in conflict with the commonly understood definition of open source and free software licensing. If it's the latter, it's just poor legalese that fails to make its intent clear. (Interestingly, the Mozilla Public License does not seem to explicitly say that there are no restrictions regarding the use of the software for any particular purpose, although that is a commonly accepted part of the definition of free software and open source.)
[1] https://web.archive.org/web/20250228155328/https://www.mozil...
[2] https://www.mozilla.org/en-US/about/legal/acceptable-use/
Those are a bunch of weasel words. You're giving a certain impression yet being vague enough that it's impossible to assess, argue or discuss the validity of that claim.
What evidence? Who are those 'some' staff? What's inexplicably wealthy?
There's a vast difference between government high-ups getting paid well and making money (as high-ups in any large organization might) and government organizations and their leadership and staff being generally corrupt.
Of course corruption is never impossible, partially because it can take forms that may be difficult to discern as such. But it's again impossible to assess that claim without substance.
I've had some crashes of Steam itself in the past and I don't know if those were somehow distro-specific.
I don't think I've run into any issues with games themselves on Steam that would have turned out to be distro-specific. Installing and running games on Steam is the same point and click exercise. Steam uses its own set of runtime library binaries for games anyway, so that probably also unifies things for games regardless of the distro.
Discord worked fine when I used it. I wasn't a heavy user though.
Someone said not to use Fedora if you have an Nvidia GPU and I have no experience with that. Also, I don't know about controllers, but I doubt those come with proprietary Linux drivers so I wouldn't assume there'd be much difference between distros.
With apt you don't have to use two separate tools to search for packages to install them. That's probably at least a moderate usability improvement for many people since you don't have to figure out whether you need to use apt-get or apt-cache for some particular command.
The GitHub discussion page in the title lists RX 6800 (and a bunch of RX 7xxx GPUs) as supported, and some lower-end RX 6xxx ones as supported for runtime. The same comment also links to a page on the AMD website for a "compatibility matrix" [1].
That page only shows RX 7900 variants as supported on the consumer Radeon tab. On the workstation side, Radeon Pro W6800 and some W7xxx cards are listed as supported. It also suggests to see the "Use ROCm on Radeon GPU documentation" page [2] if using ROCm on Radeon or Radeon Pro cards.
That link leads to a page for "compatibility matrices" -- again. If you click the link for Linux compatibility, you get a page on "Linux support matrices by ROCm version" [3].
That "by ROCm version" page literally only has a subsection for ROCm 6.2.3. It only lists RX 7900 and Pro W7xxx cards as supported. No mention of W6800.
(The page does have an unintuitively placed "Version List" link through which you can find docs for ROCm 5.7 [4]. Those older docs are no more useful than the 6.2.3 ones.)
Is RX 6800 supported? Or W6800? Even the amd.com pages seem to contradict each other on the latter.
Maybe the pages on the AMD site only list official production support or something. In any case it's confusing as hell.
Nothing against the GitHub page author who at least seems to try and be clear but the official documentation leaves a lot to be desired.
[1] https://rocm.docs.amd.com/projects/install-on-linux/en/lates...
[2] https://rocm.docs.amd.com/projects/radeon/en/latest/docs/com...
[3] https://rocm.docs.amd.com/projects/radeon/en/latest/docs/com...
[4] https://rocm.docs.amd.com/projects/radeon/en/docs-5.7.0/docs...
Of course this might still be micro-optimization from a rural Africa point of view. And a part of the reason for running the fridge is still just convention and convenience.
Of course after some point a higher rendering resolution starts giving diminishing returns if the resolution for the source material isn't also increased.
I'm also not sure that fuzzy or probabilistic properties automatically translate into reasonable transitive properties or reasoning even if the individual weights are reasonable.
(Fuzzy logic is of course exactly about formal logic and reasoning in non-absolute terms, but the idea has been around for a long time and AFAIK largely superseded by probability.)
Not that I have any deeper idea about recent work in that area. I did a couple of years' stint in semantic web stuff back in the day, and weighted relationships were one of the obvious ideas for dealing with the rigidity of explicit relationships. They also came with obvious problems and at least back then my impression was that the idea wasn't actually as useful as it initially sounded.
But as I said, I haven't really been following the field in years, so there might have been some useful developments.
It's of course based on the 8086 real mode being fundamentally limited to 1M and the 286 protected mode not being limited to that.
But if you divorce yourself from the DOS memory model, I don't think there's a fundamental need in protected mode to treat 0 to 640k (or <1M) differently from >1M, or for protected mode to have a concept of extended memory.
"One big block of 16-bit RAM" probably means the entire RAM (accessible in protected mode) addressed in 16-bit segments. If you wrote an OS that uses 286 protected mode and don't care about the DOS memory model, that's what you'd have, and there would be no need for distinguishing between "base" and "extended" memory once you've entered protected mode.
I'm not really that familiar with OS/2 so I don't know how exactly it handled the switch to real mode for the DOS session or what it did about keeping the rest of the memory separate from the <640k of the DOS session.
But in general the base vs. extended memory split is a DOS memory model thing.
Many PC BIOS implementations also reported base and extended memory separately in POST output for a long time but I think even that's just following conventions based on the DOS memory model.
https://psychnewsdaily.com/lonely-people-have-a-unique-brain...
Or is there something else I'm supposed to be seeing?
The problem is that defensive capability cannot be just built all of a sudden if it turns out to be needed after all.
Of course the reason that has become a problem is Putin's aggression and authoritarian rule.
But Europe has indeed been weak in the sense of not having maintained defensive capability. Perhaps that is, both fortunately and unfortunately, changing. (Fortunately for obvious reasons, unfortunately because it means significant spending on something that should not be necessary even though it is.)
Hopefully EU societies will remain strong and resilient in the sense they've been strong all along: strong civil society and democracy.
To be fair, historically Russia has also been a target of attacks and invasions repeatedly. (Generally not by the same smaller neighbours it has been attacking, of course.)
That history has nothing to do with the present-day conflict, though, except that it might be a part of what gives some Russians a feeling of being threatened. And Soviet-style aggression is of course just imperialism by any other name.
What has NATO (or Western Europe) told Russia to do? What is NATO threatening or attacking Russia with due to it not doing what NATO wants?