|
I would love to have something like this, Microsoft supports this, but you have to login to the Microsoft ID. I refuse to do so. i have an app in the works...
Charlie Gilley
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
Has never been more appropriate.
|
|
|
|
|
We used to use Synergy in our industrial applications. We had to split the processing load between five different machines and Synergy allowed us to easily control all of them with one keyboard and mouse. Those machines were installed about thirteen years ago.
Late last year we replaced all five machines, which were 4U boxes that each had dual six-core Xeons, with a single 2U box that has a single Ryzen 7950X (16 cores) and the performance is more than twice as fast as it used to be. We couldn't find this package commercially so we build them ourselves. Those five old machines cost about 6K each then (30K total) and the new one costs less than 2K in parts. Incidentally, we tried a machine with a 24-core EPYC CPU and another with dual 16-core EPYCs and this Ryzen is faster than both of them. We also used the EPYCs to host a high-powered GPU (A100 or A40) but our problem is so complex that the Ryzen CPU is faster than the GPUs and the CPUs by themselves. Now we use the EPYCs and GPUs for AI training and they work great for that.
Technology marches on.
"They have a consciousness, they have a life, they have a soul! Damn you! Let the rabbits wear glasses! Save our brothers! Can I get an amen?"
|
|
|
|
|
I use Input Director, a very good KVM style tool that has copy/paste among other neat little features. And it is free.
|
|
|
|
|
I used synergy some years ago across a couple of Windows boxes and a Linux box and I'm sure a Sun box was in the mix somewhere, too - it just worked really well.
|
|
|
|
|
|
|
This is exactly my type of passive-aggressive.
Sadly this one won't ship to Canada.
|
|
|
|
|
I'd never heard of it, but according to the sparse information I can find it's a sort private e-mail network that predates e-mail.
Apparently it's "popular" for EDI exchange and not much else (although the military and NATO use it, among others, because it's more secure than e-mail).
I just got a question from a client if I can deliver an EDI message via ATLAS400 instead of regular e-mail.
Seriously, as soon as someone mentions EDI I get shivers down my spine.
How can something be so ridiculously obscure and complicated and yet so popular!? 
A simple OpenAPI specification would've done the trick! (I know, EDI predates REST, JSON, SOAP and even XML...)
Anyway, it seems I need some subscription to an X.400 service and even then, there are 0 code examples on the entire internet...
So much for "industry standard" 
|
|
|
|
|
Oh man now I feel old. I think we used that on AIX machines in the early 90's.
Good luck! You've got this! 
cheers
Chris Maunder
|
|
|
|
|
Chris Maunder wrote: Good luck! You've got this! 
No I don't! 
|
|
|
|
|
And on the IBM AS400 Series.
I remember as a young "tech" , working for a company that made rubber gaskets for the auto industry.
They used to exchange orders with their European partners every night, it used to take 9 hours to exchange all these massive EDI documents, which then took another 3 to 4 hours in a complex COBOL driven process to turn the data into a human readable format.
We'd set the transfer going at 5pm when everyone left the office for the night, and it would be just finishing at about 9am the next morning as everyone started to filter in for the day.
|
|
|
|
|
Another nighttime story ...
In 1983 (*), I started working in a company developing an X.400 system. Testing interaction with other systems was essential, so those of us who kept up old contacts at our alma mater was welcome to keep in X.400 contact with them - the University ran a different X.400 implementation. The underlaying network wasn't perfectly stable, so every now and then, messages didn't make it.
One day we had a huge rush of incoming messages, some of them months old. All the missing ones were there. Where had they hidden in the weeks before?
It took a while before we found an explanation. When the University mail system failed delivery, it was configured to make a new try later - at midnight. At our company, a raw disc offline backup copy was made every day, or rather: every night, starting at midnight. So when the MTA at the U made another attempt at midnight, night after night, our mail machine was just taken down for backup.
One evening, our mail machine had a total crash. As it was already down, the operators decided to make the backup a couple hours early. The machine was back on air before midnight, ready to receive all the failing messages for months from the university. It took yet a couple days before anyone connected the early backup to the rush of emails, but when someone suggested it, the connection was obvious.
(*)
Some people claim that while internet protocols are based on real experience, real testing, OSI standards are just paperwork that never works in practice. That is of course far from truth. This was in 1983, a year before the fist official X.400 standard was passed. There were (at least) two complete, independent implementations available for testing.
But, being ahead of time can be costly. My company obviously based the implementation on working drafts. For a couple years, the drafts for the directory functions (then still part of X.400 - later to be split off as X.500) was quite stable, the implementation was based on that. A few months before the finalizing of the official standard, a major part of the directory drafts was ditched, and another alternative pulled in. My company had to do a huge crash job to implement the other alternative, the one in the final standard. (Obviously, proponents of this other alternative were from companies who had a running implementation of that alternative ready. In order to be competitive, my company had to offer the standard solution as soon as possible, not something of their own, before the competition took over the market.)
Religious freedom is the freedom to say that two plus two make five.
|
|
|
|
|
It rings a bell. Maybe bank networks, like ATM machines use it? IDK. I just think it sounds familiar.
NVM, I'm thinking of something else.
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|
X.4nn are ISO standards that describe mail systems at various levels. I assume ATLAS 400 is a product/service that supports X.400 messaging and then the question becomes how do you interface with it.
Back in the day the X.400 systems I worked with (ISOCOR, Exchange) had file gateways, you simply prepared a valid X.400 binary object and that was picked up by the mail server. ATLAS 400 may have other options, their website is in French so I can't tell.
If you need to generate X.400 objects then you'll see the standard is complicated, like all international standards, but since you're presumably only sending, and fairly simple e-mails at that, you only need to cover a limited subset. If you can't find any libraries that you can use I may be able to dig up some old code (25 years+, plain C) that might be of help. Writing it from scratch isn't terrible if you're used to reading standards, BNF etc.
I assume the EDI part is a solved problem. You probably don't want to write your own code for that.
|
|
|
|
|
gthp_cp wrote: I may be able to dig up some old code (25 years+, plain C) that might be of help.
Thanks for the offer!
We've decided this single file isn't worth all this trouble though, so I won't be needing it.
|
|
|
|
|
Certainly not "private" email! One of the reasons why it was rejected by the internet community around 1990 was that is assumed a public infrastructure comparable to the paper mail system, with post offices run by recognized authorities, strict tests for conformance before you were recognized by the post office, etc.
X.400 was standardized in 1984, with a revision in 1988 that still holds up today. (There are a few updates since, but they are rather insignificant.) From the first (1984) version, it fully handled binary body parts. All attribute strings use 8 bit character sets, transmitted in a Tag-Length-Value format, so there is never any need for quoting or escaping.
Encrypted mail was included from the very first version, and with that: Authentication.
As the mail transfer is done through a network of publicly recognized agents, you cannot fake mail: The transfer network knows where it was submitted, and verifies that the sender identification corresponds to the identity of the submitter (you must present an ID when submitting mail), so tracing/curbing a spammer would be quite simple.
The message transfer service can provide a delivery report (for non-repudiation purposes), both when the message is delivered from the transfer service to the recipient's mailbox and when the user fetches it from the mailbox into his reader.
A related service: You can submit a message for delivery at a specific time: The message transfer service holds it back at the target "post office" until the specified time, when it is delivered to the recipient's mailbox. If you change your mind before the delivery time is up, you can recall the message, and it is not delivered. (In the old days, the postal system had this service for paper mail as well: You could request a given delivery time, as well as recall mail not yet delivered.)
Chances are that you have used X.400! The major change from the 1984 to the 1988 version was not much on the functional side, but a complete reorganization of the standard content. So the directory service, developed for the address format of X.400 email, and first a part of the X.400 standard, was split off as X.500 in the 1988 version. The internet community didn't have any directory system comparable to X.500 (or if you like: X.400-and-something; I don't have that version available, but X.421 rings a bell; that may be wrong), so they developed an IP-based protocol based on X.500, leaving out the parts too complex to be implemented by sophomore or junior IT students, and called it LDAP - Lightweight Directory Access Protocol. Maybe you haven't coded the LDAP protocol yourself, but you must have been using applications that accesses LDAP directories.
Another X.400-X.500 thing you most certainly have used (maybe without knowing it): Certificates for e.g. TLS authentication/encryption are called "X.509 certificates". This was just a framework, not fully developed, in 1984, when the directory service was part of X.400. So you could argue that you are using X.500, not X.400 - but X.509 has its roots in X.400.
Baseline: X.400 was a fully matured, fully functional E-mail protocol since 1988 - almost all of it in place in 1984. In spite of threescore (or thereabouts) extensions to SMTP, it still doesn't provide the full capabilities of X.400 forty years ago.
Now, X.400 (as well as X.500) is an element in a large infrastructure, built on some rather fancy building blocks. The standard spec is based on a set of lower protocols, which are probably completely unknown to a pure internet guy. You do not sit down tonight with a beer in your hand, intending to flip through the standard so you can start coding it tomorrow morning. Learning the inner workings of X.400 and all the standards it is based on is a huge task if you know nothing of it in advance!
Your only hope is to find some implementation that you can use, and learn its interface. That will probably be some sort of "P7" protocol implementation - how to access your mailbox. The protocol between the mailbox and the transfer service is the "P3" protocol, and is significantly more complex. That is not a place to start!
Note that X.400 (like all other X.*** protocols) defines all the details of what goes across the line. It also defines how you submit and receive data, but there is not a one-to-one relationship between your calls and the network transfers. Sometimes, the connection between the two is rather vague (at least until you learn the inner workings).
If you are going to use X.400, rather than implement it, you can forget about the line protocol, and rather study the service interface (a.k.a "API). The standard defines the services (calls), and the parameters in an abstract sense: Details of what kind of values, in which structures, but nothing about how these are realized in a specific language or on a specific machine - that is all "a local matter". You have the freedom to do it just the way you like, as long as it comes down to the standard line protocol elements.
When you find yourself a P7 implementation for your OS and machine, that implementation has made some decisions about how the abstract data objects are implemented as concrete ones, and you must dance to that fiddle.
If you decide to jump into this vast ocean  , X.413 is the document where you find the P7 service definitions. X.419 documents the line protocol. But you can't just read these two alone - most of the stuff from X.400 to X.420 is "required basic knowledge" for any sort of implementation, even if you are just implementing the message store (mailbox) with P3 in one end, P7 in the other. You find them all at https://www.itu.int/itu-t/recommendations/index.aspx?ser=X[^]; click "X.400-X.499: Message Handling Systems" and navigate from there.
But you are not done with that! You will need to learn ASN.1 (in the X.68x series) and ROSE (in the X.88x series) just to understand the X.400 standards. Then comes ACSE (X.217) and Reliable Transfer (X.218/X.228), and most likely a few more.
* * *
One thing that is not clear to me: You can develop an EDI application, and feed it through your mailbox to the X.400 network. But: Is there an X.400 network you can mail it to? I am not familiar with ATLAS400, it seems to be an X.400 network of sorts, but how can you access it? How can the customer access it? Does it provide an X.400 MTA (Message Transfer Agent, a "post office")? Do they offer a message store to be run centrally? Or to be run locally at your PC? Do they provide documentation of their P7 API? (I really should say "message store API", you don't have an API to the protocol).
Seems like there are lots of open ends here!
* * *
While OSI protocols are really tough get under your skin: If the tools are in place, as well as good implementations of all lower layers, and you know the formalism, the definition languages, and you have proper tools: Adding an application such as P3 or P7 (or the X.500 directory protocol) is just the frosting on the cake. The final touch. Almost no work at all, compared to implementing it all the way to the bottom.
You are not in that situation.
Bottom line: Even if you find some suitable message store implementation (P7 protocol) I think your task will be formidable, if you have no background in OSI protocols. To be frank: I do not expect you to succeed. (But kudos to you if you do succeed!)
Religious freedom is the freedom to say that two plus two make five.
|
|
|
|
|
trønderen wrote: One thing that is not clear to me: You can develop an EDI application, and feed it through your mailbox to the X.400 network. But: Is there an X.400 network you can mail it to? I am not familiar with ATLAS400, it seems to be an X.400 network of sorts, but how can you access it? How can the customer access it?
My customer now gets some EDI file (that is a .txt file with the cryptic contents that make up an EDI message) from some application and they simply e-mail it to their customer.
Now the customer has requested to get it through ATLAS400, but none of us heard about it and they simply asked me if I knew it and if I could do it.
My answer will be "no"
I mean, I could do it, given enough time and money, but for that single (probably monthly) file, it's simply not worth it.
Thanks for the history lesson though!
trønderen wrote: Certificates for e.g. TLS authentication/encryption are called "X.509 certificates".
This one blew my mind! 
|
|
|
|
|
It has been operating for decades without reinventing the wheel at the arrival of new paradigms so it is well thought out and designed.
Besides that, nothing that works is simple.
|
|
|
|
|
I can't think of anything that is well thought out and designed, yet has made a great success in the IT/networking world. All the well designed languages flopped. All the well designed data representation formats. All the well designed protocols.
People do not want good design. IT people in particular, but certainly not limited to them. No well designed human language has made any great success, either!
Religious freedom is the freedom to say that two plus two make five.
|
|
|
|
|
|
Well, that's a little disturbing. A human driver would not stop for a person wearing a "STOP" T-Shirt. Imagine what might happen if a self driving vehicle encountered a person wearing a "Speed Limit 100" T-Shirt! Clearly the Traffic sign detection algorithms need improving.
One has to wonder how they might deal with some of these: The 20 Most Confusing Road Signs Ever
"A little song, a little dance, a little seltzer down your pants"
Chuckles the clown
|
|
|
|
|
Brings up a serious question.
What about flagman/person who are controlling the traffic flow when a construction crew is occupying one lane of a two lane road. They often have hand held stop signs, but it is not a stop and go situation. You have to wait for the flagman to flip the sign around to the "Slow" sign to safely cross over into the other lane of traffic to get by the work crew.
|
|
|
|
|
|
Lol! Waymo would have a nervous breakdown if it encountered this traffic cop.
|
|
|
|
|
Wordle 1,068 3/6
⬛⬛🟩⬛🟨
🟩🟨🟩🟨⬛
🟩🟩🟩🟩🟩
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
