A bold take on Docker, Kubernetes, and the future of software deployment—share your thoughts below! #Virtualization #Containerization #Docker #Kubernetes #SoftwareDeployment #EfficientResourceUtilization #Scalability #Portability #CloudComputing #TechTrends #DevOps #ITInnovation #RealWorldImpact #CyberSecurity #OpenSource #ITLeadership #TechTalk #FutureReady #ShareYourThoughts #BoldTech #Community #TechFuture #SEO #Keywords
https://medium.com/@sanjay.mohindroo66/virtualization-containerization-the-new-era-of-software-deployment-3f819c7a91c0
#Portability
Next #swad improvement: Make sure to #wipe #passwords from RAM directly after used. That's more of a #security precaution, because there *should* be no way how an attacker can access a running process' memory, but you never know which bugs surface 🙈.
Unexpectedly, that posed #portability issues. #C11 has #memset_s ... a pretty weird function, but suitable for wiping. It's there on #FreeBSD and on #OpenBSD. Not on #NetBSD though. But NetBSD offers the much saner #C23 function #memset_explicit. Looking at #Linux, there's neither. But there is the (non-standard!) #explicit_bzero 🤯 .. and with glibc, it requires _DEFAULT_SOURCE to be defined as soon as you compile with a C standard version given to the compiler. This function exists on some other systems as well, but there's confusion whether it should be declared in string.h or strings.h. 🤪
Here's the full set of compile-tests I'm now doing, only to find the best way to really erase memory:
https://github.com/Zirias/swad/blob/master/src/bin/swad/swad.mk#L6
And if none of these functions is found, swad uses the "hacky" way that most likely works as well: Access the normal memset function via a volatile pointer.
Our motto is »#Linux #OpenSource News & #KnowHow for #Office Tasks.«
Our posts are for #solopreneurs, #trainers, #facilitators, and everybody else who tackles their office tasks using open source software under Linux.
While we appreciate #portability, we're strictly Linux-only. With respect to other operating systems: no bashing, no praise, no comparisons. We've already made our choice.
Formerly @social.tchncs.de, 2021-09-01 to 2024-06-15; then @mastodon.de until 2025-04-17
@GossiTheDog "Mastodon" really needs to get cracking on full data portability, IMHO.
It's a shame this hasn't been pushed higher up on the list of things to do.
I think many people have invested quite a bit of time and effort into their posts and profiles, and moving all that data, or somehow managing a switch-over doesn't seem to be that simple, if at all possible.
[Перевод] Переносимый код: Fighting the Lemmings
Сергей Каличев, старший разработчик, Angie Software Однажды, давным-давно, я наткнулся на одну хорошую статью по разработке переносимого кода и решил её перевести. Когда же это было... ё-моё, в 2008 году, 17 лет назад! Обалдеть, как время летит. Статья называлась "Fighting the Lemmings", автор Martin Husemann. Выложил перевод на LOR . С тех пор много воды утекло и, когда я попытался поискать статью в Интернете, то обнаружил, что ни оригинальной статьи, ни перевода, найти практически невозможно. Перевод ещё сохранился в глубоких закромах OpenNet , а оригинал только в архиве Интернета . Ссылки на PDF-ки тоже протухли и больше не работают. Обидно, это ведь такая нетленка для системщиков. Понятно, что переносимость уже сто раз пережёвана в других статьях и книгах, но тут всё было сконцентрировано и написано доходчиво. При этом актуальность до сих пор не потеряна. Ну а что, собственно, кардинально поменялось в разработке переносимого кода на C с тех пор? Если не обращать внимание на упоминания некоторых архитектур и ОС, которые сейчас, да и во времена перевода, звучат, как придания старины глубокой, то в остальном, обо всех особенностях разработки переносимого кода, описанных в статье, надо помнить и сегодня. Выкладываю текст, как он есть, без каких-либо современных правок. Для тех, кому удобнее читать в PDF, вот ссылки: PDF оригинальной статьи PDF перевода А теперь сама статья.
https://habr.com/ru/articles/890530/
#C #code #portability #переносимость #unix #linux #endianness #align #выравнивание #lemmings
Big question, Why ATProtocol from #BlueSkySocial #PBC’s mouth instead of Mastodon and ActivityPub?:
“Why not use ActivityPub? #ActivityPub is a federated social networking technology popularized by #Mastodon.
Account #portability is a major reason why we chose to build a separate protocol. We consider portability to be crucial because it protects #users from sudden bans, server shutdowns, and policy disagreements. Our #solution for portability requires both signed data repositories and #DIDs, neither of which are easy to retrofit into ActivityPub. The migration #tools for ActivityPub are comparatively limited; they require the original server to provide a redirect and cannot migrate the user's previous data.
Another major reason is #scalability. #ActivityPub depends heavily on delivering messages between a wide network of small-to-medium sized nodes, which can cause individual #nodes to be flooded with traffic and generally struggles to provide global views of #activity.”
Short version, WE CANT CONTROL YOU.
At Artinis, we believe neuroscience research should go beyond the lab, which is why our devices are designed to deliver exceptional performance wherever it's needed—even at home.
🟡 Elderly Rehabilitation: A recent study by Klop et al. showcased the diagnostic potential of using the PortaLite MKII to monitor brain activity during rehabilitation for orthostatic hypotension —right in patients’ homes.
https://publications.artinis.com/publication/klop-home-based-2024/
4b. Some companies or PR people may answer that data #portability is on their roadmap. Ask where the roadmap can be checked out
Something I hadn’t considered about account #portability …
It will simplify initial user onboarding. Interested in XYZ software? Cool. Sign up now on xyz.social. You can move your account in a week or two once you have a lay of the land…
This might actually provide the critical mass needed to get this technology rolling.
While we still need to resolve the issues of #backups and #portability, there are services like #ProtonPass that can handle this for you (if you want to #trust them).
https://www.theregister.com/2024/12/18/microsoft_passkey_push/ #passwords #passkeys #authentication #authenticity #SecureLogin
Resumed Technical Comparison: Linux vs. BSD
Linux and BSD are two influential families of open-source operating systems with distinct philosophies, architectures, and use cases. Although they share UNIX roots, their development paths, licensing models, and system design set them apart.
Read More: https://machaddr.substack.com/p/resumed-technical-comparison-linux
#BSD #RUNBSD #Linux #Comparison #Use #Cases #Operating #Systems #OpenSource #Portability #Security #OpenBSD #NetBSD #FreeBSD #Technical #Review #Computer #Science
Can #C be liberated from its ultra-#portability fantasy? One #proposal at a time.
Two’s complement & IEEE-754 arithmetic next?
“P3477R0: There Are Exactly 8 Bits In A Byte”, JF Bastien (http://wg21.link/P3477r0).
@reichenstein Consider filing an #antitrust #complaint.woth @EUCommission and your local #AntiCartelWatchdog to enforce #EU #Cloud #Portability legislation...
While it appears that everyone else has posted this (for good reason), there remains a chance that someone just arrived and might have missed the talk by (then) US Navy Captain Grace Hopper, "Future Possibilities: Data, Hardware, Software, and People", at the National Security Agency (NSA) in 1982.
Split across two videos posted on YouTube, this talk covers such a range of topics with such insight and current applicability and with Feynman level wit and style [Both praise and description] that I won't try to list any, but refer you to the previous posts.
Watch both, but if some tragic constraint prevents this, then watch the (slightly shorter) second video.
Rear Admiral Hopper retired from the US Navy - for the second time - in 1986 at the age of 79.
https://www.nsa.gov/Press-Room/Press-Releases-Statements/Press-Release-View/Article/3884041/nsa-releases-copy-of-internal-lecture-delivered-by-computing-giant-rear-adm-gra/
https://youtu.be/si9iqF5uTFk
https://youtu.be/AW7ZHpKuqZg
#GraceHopper #USNavy #NSA #Computer #SystemsArchitecture #Scaling #Cluster #Portability #InfoSec #Diversity #Mathematics #Physics #Leadership #Management #CriticalThinking #Inspiration
New on blog: "Overview of cross-architecture #portability problems"
"""
Ideally, you'd want your program to work everywhere. Unfortunately, that's not that simple, even if you're using high-level "portable" languages such as #Python. In this blog post, I'd like to focus on some aspects of cross-architecture problems I've seen or heard about during my time in #Gentoo. Please note that I don't mean this to be a comprehensive list of problems — instead, I'm aiming for an interesting read.
"""
https://blogs.gentoo.org/mgorny/2024/09/23/overview-of-cross-architecture-portability-problems/
Are we doing fun stuff with #CPython right now? Perhaps.
A few tests were failing when `systemd-nspawn` was used with `--suppress-sync=true`. Why? Because it uses SecComp to override sync-related syscalls with no-ops. And no-ops always succeed, even with invalid arguments. Some of CPython tests were testing that exceptions are raised with invalid arguments. So I wrote a function that specifically detects this scenario, and skips these tests.
https://github.com/python/cpython/pull/124215
Other tests were hitting a segfault on PPC64 (BE). As I've mentioned before, I couldn't figure out the cause. GDB suggested it's happening in malloc(). If I added `--with-pydebug`, the segfault disappeared. If I enabled ASAN, it disappeared. Finally, @thesamesam discovered that it's a stack overflow due to deep recurrence. What's really interesting, if we look at the context of his patch, we'd understand why my attempts failed. Python is using a lower recursion limit if either `--with-pydebug` is used, or ASAN is enabled.
I've decided to check the stack frame size across different architectures. With GodBolt's help, I've discovered that (of the platforms covered by it) only PPC64, s390 and SPARC are using absurdly large stack frames. Interesting enough, PPC64LE has them a little smaller than PPC64. Here, pkubaj suggested that it's because LE uses -mabi=elfv2 by default, while BE -mabi=elfv1.
https://github.com/python/cpython/pull/124264
I was also thinking some about safe migration paths to 64-bit time_t on 32-bit platforms — but that's another story.
@portaloffreedom It really depends on the app, but I'm finding that generally, things are looking up. #Signal is quote good, and #Element / #Matrix .org is working on it.
I understand what you're saying about the #portability of #pgp, but the #UX is terrible.
Have you read Signal Developer Explains Why Early Encrypted Messaging Tools Flopped (https://www.pcmag.com/news/signal-developer-explains-why-early-encrypted-messaging-tools-flopped)?
Against all odds, #32bit #time_t is sometimes helpful.
For example, yesterday I've found an interesting bug in the #Moto library. It was passing to botocore a date that resembled ISO-8601, except it did not use any separators, e.g. "20240907201715" — while botocore expected either numeric UNIX timestamp, or a more typical date format. As a result, the joined digits were incorrectly interpreted as a UNIX timestamp, giving a date in the year 643378.
I suspect that if not for 32-bit time_t failing on timestamps this large, for a long time nobody would have noticed the dates being misinterpreted.
I'm slowly working on a new blog post. In the meantime, I've looked closer at the #y2k38 problem, and I'd like to share some observations with you.
It seems that the problem is mostly considered from the "overflow" in 32-bit programs angle — i.e. that we're suddenly going to move back in time from 2038 to 1901, and there will be some "funny" effects of that. However, in reality we're probably going to see different kinds of problems.
Firstly, `stat()` stops working on files whose timestamps can't be expressed in 32-bit `time_t` (the files can still be opened, though). It is quite counterintuitive; we usually assume that opening files is more restrictive. In the most absurd case, a program would be able to use a file only once. Once used, timestamps will get updated and `stat()` will start failing.
Secondly, `time()` returns an error. Many developers (myself included) doesn't even consider that `time()` can fail. Yet after 2038, every single call is going to return `-1`. What does that mean? A "well-written" software will just fail with an error. Other programs will just be "stuck" 1 second prior to midnight of December 31, 1969. And I believe that could be worse than returning an "overflowed" time counter, as every call will return the same value.
What could the consequences be? Clocks showing the same date and time all the time. Waiting loops based on wall clock time hanging immediately. Events never getting triggered. Clock-seeded pseudorandom number generators (`srand(time(NULL))`) always returning the same sequence of numbers.
This will affect all proprietary software on 32-bit platforms. If we wanted to play an old game, we're going to have quite a fight ahead of us. What's even worse, even faketime doesn't suffice here — it will adjust the time returned by `time()` calls, but not file timestamps.
@viq By #open #saas, I mean software that's #opensource, but somebody else is managing it for your so that you don't have to. So you get all of the benefits of open source (e.g. #portability) as a service that you pay for.
I'm working on @backupscale right now, which is another example: securely #hosted #Restic respositories with #ransomware protection. You can set up your own backup system the same way, but it's tricky so that's why we're offering it as a service.
Client Info
Server: https://mastodon.social
Version: 2025.04
Repository: https://github.com/cyevgeniy/lmst