> Finnix 0.01 was based on Red Hat Linux 6.0, and was created to help with administration and recovery of other Linux workstations around Finnie's office.[citation needed] The first public release of Finnix was 0.03, and was released in early 2000, based on an updated Red Hat Linux 6.1.
As far as I understand there are multiple XML invoice formats and EN 16931 accepts at least two: UBL and CII. At least in theory. I have no idea how it is going to work out in practice, but I will learn the hard way :-) I have invoicing software as side-project and I have decided to make it usable in EU.
> People will generally follow an optional standard to make their own lives easier
You must be new to the internet /s
A company does not gain anything by sending "better" invoices that follow a standard. Only if they receive standardized invoices, but usually not enough to pay extra for it. The fact that standardized invoices haven't happened yet without legislation should be proof of that
To be clear: The ones who need to follow the standard (companies that create invoices) do not need access to the standard, only some supplier does. And there are a lot of things that the government requires that costs money - you could see it as another tax.
That said, I actually agree with you - it's crazy that we need to pay for a stupid standard document.
> In 1990, both Ritchie and Thompson received the IEEE Richard W. Hamming Medal from the Institute of Electrical and Electronics Engineers (IEEE), "for the origination of the UNIX operating system and the C programming language".
> In 1997, both Ritchie and Thompson were made Fellows of the Computer History Museum, "for co-creation of the UNIX operating system, and for development of the C programming language."
> On April 21, 1999, Thompson and Ritchie jointly received the National Medal of Technology of 1998 from President Bill Clinton for co-inventing the UNIX operating system and the C programming language
Have you ever tried to get a game developer to open source a game? And a Japanese one at that?
Even if they were willing to (they're not) and if they still have the code (they don't), it will contain proprietary code from Nintendo and you'll never get your hands on that (legally)
Reading through that site, it seems like instead of locking yourself into a corporations app, you're locking it into his instead. He doesn't seem to want to run an open source community, he's building an app for himself and publishing it for people who have exactly the same use case as him.
True, but you don't need to install updates once you have the software installed, and it's probably better not to. The software on the robot doesn't need the app to control, either - it exposes an API that either the app or custom software can talk to, sans cloud servers.
Man, I remember a few years ago when I was in a place without good Internet reception, but good enough phone reception. Wanted to send a SMS instead of a WhatsApp message and only noticed hours later that my phone switched to RCS without fallback and my "SMS" didn't go out because of the missing internet connection.
I disabled RCS that day and never enabled it again.
2G and 3G networks are dying. 4G+ is entirely packet based. "Phone reception without internet reception" simply isn't a thing once the final analogue networks die out. That's what RCS is built for.
RCS has the advantage of theoretically being able to get priority through the baseband, but if you're using Google's RCS servers rather than your carrier's, that's not going to work.
No, RCS is 'built for' a cheap and thinly vieled attempt for carriers to retain some control over messaging. Oh, and for mass surveillance purposes.
It's not a coincidence that RCS still requires carrier hardware and coordination, despite being an IP messaging protocol. It's also not a coincidence that the protocol did not feature E2EE, despite even student project protocols providing that.
> RCS has the advantage of theoretically being able to get priority through the baseband, but if you're using Google's RCS servers rather than your carrier's, that's not going to work.
Phone calls also can get priority over plain SIP traffic and SMS messages get transmitted on mobile networks before 3G connections are established to send Teams messages. I don't think net neutrality laws covers carrier network functionality like this.
> and SMS messages get transmitted on mobile networks before 3G connections are established to send Teams messages.
this is different as you already explained
Net neutrality:
> Net neutrality is the principle that internet service providers (ISPs) treat all online traffic equally and openly, without discrimination, blocking, throttling or prioritisation.
I know what net neutrality is. I just doubt it applies to RCS. Packet switched versus circuit switched transmission of digital messages is just an implementation detail.
With the introduction of LTE, everything from calls to texts have been IP based TCP/UDP/maybe SCTP packets. Does WhatsApp get to file a net neutrality violation because the phone's native SIP client gets priority by the modem/carrier? Does Gmail get to file a claim because SMS messages exchanged through SIP are delivered faster than their push notifications? Does Telegram get to file a claim because you have to pay for a megabyte of roaming costs traveling abroad while you only pay for a single "SMS" despite both being a TCP packet? I don't know. I don't expect those claims to apply.
RCS is the same, in that it's a core carrier feature that communicates between your phone's messaging service and your carrier's infrastructure. RCS' envelope is actually quite similar to MMS' design, except MMS' data transmission still had to be implemented in a circuit-switched way because it came from the 3G era.
Google muddied the water by offering carrier infrastructure (an RCS server) worldwide to any phone that wants to connect to it. It's as if I would host my own SMSC I'd let anyone in the world connect to. It's not the normal use case and as carriers are implementing their own RCS services, I expect this anomaly to slowly disappear over time.
The distinction between third party messengers and SMS/MMS/RCS is a good thing, in my opinion. SMS/MMS/RCS providers need to be able to exchange what is essentially a live feed on a phone number with law enforcement at a moment's notice. Messengers like Signal don't. If third party services would fall under the same category as RCS, it'd stand to reason that the same would also apply in terms of law enforcement orders, and I don't think anyone but the law enforcement agencies would want that.
IMS traffic (voice & conventional SMS) runs on a different PDP context or "bearer" (think "VLAN" but on the cellular interface) which is prioritized at the network level over the general-purpose internet access bearer. I assume that if RCS is offered by the carrier then it would also be running over a dedicated bearer.
I haven't seen separate APNs for RCS here†. Since the iOS support, what "offered by the carrier" means in most the world is only (de)registration through IMS service entitlement. Unlike the Google Jibe / Messages pairing done OTT using an SMS token to check your phone number, which is still the case in a lot of countries. Once the registration established, it's plain data traffic to Google servers.
† Here = "global" RCS, de facto controlled by Google. I haven't checked carrier settings for RCS islands such as the deployment in China or Korea.
> Finnix 0.01 was based on Red Hat Linux 6.0, and was created to help with administration and recovery of other Linux workstations around Finnie's office.[citation needed] The first public release of Finnix was 0.03, and was released in early 2000, based on an updated Red Hat Linux 6.1.
So it seems that it was based on Knoppix later