Or the comment sections could just be merged together in the client view. Each thread of comments would belong to one (and only one) instance, so it shouldn’t be difficult to merge those lists together when presenting the aggregate view to the user.
Or the comment sections could just be merged together in the client view. Each thread of comments would belong to one (and only one) instance, so it shouldn’t be difficult to merge those lists together when presenting the aggregate view to the user.
That’s unfortunate.
Instead of requiring an insurance selection or defaulting to one specific instance, perhaps they could have a handful of moderate/large instances that the app randomly selects between when a user signs up. That would spread out the signups from people who don’t understand the instances.
We could always move Veteran’s Day to September but then establish Armistice Day on 11 November, which is what the rest of the world calls that day. Net result would be one more federal holiday (just with some renaming).
Or, we could mess things up by leaving Labor Day and Veteran’s Day alone and adding “Armistice Day” in May. :)
I’m hoping that, someday, we have support for what I described in another post:
It would be very beneficial to have clients that support aggregating equivalent communities from multiple instances. When viewing a post from the aggregated community there could be a section at the top saying “Viewing comments from:” and then a dropdown to choose between “all instances”, “lemmy.world”, “lemmy.ml”, etc. When viewing all comments, they would be in one combined feed, without the user needing to care about which underlying post holds the specific thread they’re looking at.
Similarly, when users post something to an aggregate community, they could select whether it’s posted to all the included communities, only one, or some specific subset.
It would be very beneficial to have clients that support aggregating equivalent communities from multiple instances. When viewing a post from the aggregated community there could be a section at the top saying “Viewing comments from:” and then a dropdown to choose between “all instances”, “lemmy.world”, “lemmy.ml”, etc. When viewing all comments, they would be in one combined feed, without the user needing to care about which underlying post holds the specific thread they’re looking at.
Similarly, when users post something to an aggregate community, they could select whether it’s posted to all the included communities, only one, or some specific subset.
Videos are not documentation.
They can be used to demonstrate examples of how to do a particular task, but as other commenters have mentioned, documentation involves listing classes, functions, parameters, etc and clearly explaining what they all do, in a searchable manner. Text is searchable, video is not.
Nope, I absolutely hate Jira and everything that I needed to do in it at my old job. Luckily for most stuff we had other issue trackers (multiple, but that’s another issue), but whenever I had to touch Jira or any other Atlassian tool, it was a bad time.
They’re way too expensive and they’re still early-generation devices. Plus, why would I trust Google to continue with the product line seeing as how they keep killing viable products and services?
If they get to the Pixel Fold 4 or 5 and the price is down to the $500-600 range, then it’d be a very serious contender for me. (Assuming the insane fragility is resolved)
I freaking hate Shorts, and the persistence with which YouTube attempts to shove that crap down your throat is absolutely infuriating.
YouTube also recently made the thumbnails larger, which is also really bad as it makes it more difficult to see what videos are in your subscription feed (even moreso with all the shorts clogging it up).
The only use that I’ve thought of over the years is event logging where you need a very high confidence that no one has tampered with the logs.
For consumer software, yes, most is still being built with a baseline target instruction set from the early/mid-2000s. In 2019 there were reports of Apex Legends requiring SSE4.1, an instruction set from circa 2007. It will be be probably close to a couple decades before consumer software would start commonly requiring these instructions.
However, for more specialized environments, such as scientific and high-performance computing applications, it’s much more common that you will be using custom software designed for a specific task, and that it’s normal to recompile the software when you get a new set of hardware. In those applications, these instructions can make a huge impact, as you know exactly which capabilities are supported by the hardware and can use everything available.
I believe there are also some (possibly limited) situations where a program can check what instructions a processor supports and use either the newer (higher-performance) version or the slower, more widely-supported version depending on that check. There may be limits on how often that can be done however.
If you want to share a video, unless it is your own, original content, you should be linking to the original source, not uploading the video itself to Lemmy. Uploading content that for which you do not have rights to a platform is freebooting, and is theft. Linking to the original source lets you share the content with others while still providing the views and revenue to the actual creator, ensuring that they will be able to continue making the content that you have evidently found value in.
tl;dr - link to the original source, don’t upload someone else’s video to the platform.
jQuery is a JavaScript* library that played a really important role in adding interactivity to websites and doing so in a way that works across browsers. Its capabilities were fantastic for its day, but newer iterations of JavaScript and subsequent frameworks and libraries (such as Angular, Vue, Svelte, and React) generally provide the same capabilities in a form that is easier to work with. Most new sites use those newer tools, but jQuery was one of the key technologies behind the kind of interactive websites from the mid-2000s until the mid-2010s (essentially the heyday of Web 2.0 (RIP)), and is still used in websites from that era that haven’t needed huge overhauls since then.
Or what if a user could see their own karma, but no one else’s? If karma isn’t publicly visible, then people may care less about it.
Unfortunately the software industry (at least in the US) has applied the term “engineer” basically across the board to software developers instead of only for properly trained and licensed engineers as in other fields (civil engineering, mechanical engineering, etc). Part of this is due to a lack of a formal software engineering licensing system, but the desire for fancy titles is certainly something that played a role in this.
My understanding is that other countries, like Canada, do have strict requirements for the use of the term “engineer”, but unfortunately that ship appears to have sailed in the US due to inertia and the intransigence of Silicon Valley-type companies.