>SIEMENS Sibas 32, 6FH6035-1A + 4x 6FH 9543-3BY60 + 6FH 9533-3BY60 + 6FH 9550-3AY60 + 3x 6FH9485-3A + 6FH9484-3A + 6FH9498-3A + 6FH9481-3B Antriebssteuergerät
7500 EUR, 28 kg (found after a quick search).
217 karma · joined May 6, 2015
>SIEMENS Sibas 32, 6FH6035-1A + 4x 6FH 9543-3BY60 + 6FH 9533-3BY60 + 6FH 9550-3AY60 + 3x 6FH9485-3A + 6FH9484-3A + 6FH9498-3A + 6FH9481-3B Antriebssteuergerät
7500 EUR, 28 kg (found after a quick search).
I guess with some luck you can work on these hardware drivers for Windows 3.11 at home without any access to the network or train. What you need are specifications and maybe some part of the system, maybe there is some simulation software for the internal system of the trains.
I mean the alternative is that you have to work in the train.
*Update:* Since the SIBAS 32 system is just a box someone can sent home to you, you can probably connect a computer with Windows 3.11 to it, and run some simulations on the SIBAS system.
The text is probably translated from German. In this case they did not mean correct pronouns, but they meant they did not use inclusive nouns for simplicity reasons.
But even "masculine form" makes no sense. "vehicle control system" is neutrum in German and "high-quality display software" is female. Makes not sense to use masculine form here.
I think they can't update the internal system responsible for the engine and brakes that easily, as well as the cockpit control systems.
But the system that displays the time and the next stations. With some investment you can communicate via serial or parallel port with the internal system. I guess using the WIFI for this instead would be a problem with security and reliablity, so they have to use the internal system.
The ICE 1 and ICE 2 trains use this for their internal system. Deutsche Bahn will keep them running until at least 2029 (ICE 1) and 2030 (ICE 2).
A co-worker showed me a video of a display of the passenger information system that boots in MS-DOS and then restarts after it fails to load network drivers. BIOS from 1996 (166 MHz, 8 MB RAM). I guess they also need some people to maintain network drivers (and serial/parallel port drivers and the applications using it).
SIBAS is also used in Japanese and Swiss trains.
But what is evidence? A photo of a sea monster in a Scottish lake can be evidence. Or a NASA photo of a large face on mars. In both cases misidentification of objects is probably involved.
Then there is a category of evidence that is difficult, time-consuming and/or non-intuitive to understand, e.g. climate change.
An interesting incidence/problem report is in [2] at 1h:03m:00s, where an replication error in their Riposte message store system is described. After a defect counter hardware was replaced, it will fill its empty store with messages from other counters.
[1] "Technical Appendix to Judgment (No.6) “Horizon Issues”", https://www.judiciary.uk/wp-content/uploads/2022/07/bates-v-...
[2] "Alvin Finch - Richard Coleman - Day 54 AM (17 May 2023) - Post Office Horizon IT Inquiry", https://www.youtube.com/watch?v=H0_-ebCVU5k&t=3780
[3] Steven Murdoch: "What went wrong with Horizon: learning from the Post Office Trial", https://www.benthamsgaze.org/2021/07/15/what-went-wrong-with...
>Post Office Scandal Explained https://www.youtube.com/watch?v=LdQQib3rmkE
>Is Horizon still being used? >Yes. There have been several versions of Horizon since its introduction in 1999 and the current version of the system, introduced from 2017, was found in the group litigation to be robust, relative to comparable systems. But we are not complacent about that and are continuing to work, together with our postmasters, to make improvements. We will be moving away from Horizon to a new IT cloud-based system that will be more user-friendly and easier to adapt for new products and services. This is currently being developed with the involvement of our Postmasters.
via: https://corporate.postoffice.co.uk/en/horizon-scandal-pages/...
It was not only the bugs but also the UX and the overall process that made things worse.
The system did things that the postmaster was either unaware of, or did not intend to do. When there was a customer session and a session time-out occurred it was changed into an actual transaction without the postmaster intending it; like you have a shopping cart on an e-commerce site and it transforms the shopping cart automatically into a sale after timeout.
There were screen freezes and when the postmaster pressed enter while the screen freeze happend, it multiplied the amount of money, without the screen being updated.
Postmasters are responsible for discrepancies, and when they called the telephone support they were occasionally told "not to worry, it will sort itself out". There were corrections from the outside and postmasters sometimes waited for weeks and even months for these corrections to happen to resolve the discrepancies. Sometimes they never happened.
They inserted transactions for corrections of discrepancies where you could not see they were authored by them; it was just assumed the postmaster did.
They did not let postmasters know about this; probably an order by the post office.
These corrections where incorrect, and caused discrepancies to increase; they mixed plus and minus sign quite often.
They added lines of code to the system running on the counter in the local post office.
They used the message store system like wild west without defining a data schema.
Print-outs of the support system tickets are shown in the inquiry [1] (e.g. the ones with former technical support engineers). For instance, there is one from October/November 1999 with conversation history of people from different levels of support, where you can see they (the support and software engineers) knew the exact amount of money missing and that the caller was "very agitated as he keeps having problems with the system when balancing. He thinks it is a system problem".
I haven't seen support system tickets where they stated the discrepancies were caused by Horizon in the inquiry (obviously in court they proved there actually were), but I only watched a few hours of this so far. And the support engineers stated they did not grasp the implications of the callers having discrepancies.
The support engineers even visited the callers on-site.
[1] https://www.youtube.com/@postofficehorizonitinquiry947/video...
The concept looks really nice on paper, also the network communication considerations [2]. But there were bugs in Horizon like when a notebook at a post office was shutdown before a certain time, there were no day-end-markers added to the last transaction, and it seems they had no concept to let the system check this on the next day. There were bugs where the start times for transactions where missing, and these transactions were filtered in certain views however these messages eventually were transmitted.
[1] FUJ00080526 - Fujitsu Report Horizon Data Integrity v1.0, https://www.postofficehorizoninquiry.org.uk/evidence/fuj0008...
[2] WITN00780100 - Richard Roll - Witness Statement.pdf >[...]there were several different types of configuration, depending on the type of PO (mobile, single counter, multi counter or main PO with a separate gateway computer), but from the SPM's perspective these would have all looked the same. >General security protocols were in place at the PO's. Secure passwords were required, which were not supposed to be shared but often were. There was a secure link from the PO counter to Fujitsu's servers —the counters would only respond to requests originating from specific telephone numbers —and all data was encrypted. Additionally, the network was completely (logically) isolated form the internet, it had its own dedicated lines[...]
That's not true.
>Richard Roll is the real life Fujitsu whisteblower behind the character in Mr Bates vs The Post Office who lifted the lid on the faulty computer system.
I've watched some parts of [1] on youtube, and it seems the riposte system is on the machines in the post office. if it is also used in headquarters, I don't know. they have messages that have incremental sequence numbers to identify the replicates messages.
messages are put into the message store where each message has a checksum. when a message is read and gives a CRC error, someone raises a call, and they rebuild the message store. which recalculates the checksums, I assume.
CRC errors can be caused by data corruption on the counters. so this implies data is stored on the counters. when they rebuild the message store it seems they can use data from the other counter which hopefully has no corrupted message (but the former software engineers can't quite remember if this was true, at least she says so). so it seems they have redundancy between these counters. when CRC erros happen often, they'll replace the counter.
I also assume they describe the Horizon system pre-2010.
[1] "Anne Chambers - Day 67 AM (26 September 2023) - Post Office Horizon IT Inquiry", https://www.youtube.com/watch?v=q72zvd9Iz3Q
Post office should have used your Turbo Pascal-based system, the post master would not be forced to become a taxi driver.
This reminds me I always wanted to build a fictional cashier system with terminal interface in ncurses, after I saw these still used in early 2000s in DIY stores. Maybe a local post office system would also a great side project for the weekends.
Regarding software bugs in Horizon: Some of the bugs are mentioned in the early chapters in the book by Nick Wallis. I first read an article by the Guardian which only mentioned two of the bugs (as far as I remember) but also said many other bugs were discovered [1]. I first thought these were mostly UX issues [2] [3] that caused user input errors, but reading some of the inquiry reports and the book made it more apparent that there were system bugs, e.g. [4] on top of a sub-optimal message system [5]. Of course, you can say UX issues are also some kind of bug, error or defect.
[1] >As early as 2001, McDonnell’s team had found “hundreds” of bugs. A full list has never been produced, but successive vindications of post office operators have revealed the sort of problems that arose.
[2] >“The Dalmellington Bug entailed a user repeatedly hitting a key when the system froze as she was trying to acknowledge receipt of a consignment of £8,000 in cash. Unknown to her each time she struck the key she accepted responsibility for a further £8,000. The bug created a discrepancy of £24,000 for which she was held responsible.”
[3] >"If a bunch of products sit in a basket for long enough on the screen Horizon will turn them into a sale automatically." -- ‘It is an example of Horizon doing what it was supposed to do.’ -- ‘It is evidence of the system doing something without the user choosing to do it.’ retorts Mr Coyne. >"This stance of blaming the users if they were confused by Horizon’s design was taken to an extreme with “phantom transactions”. These were transactions generated by the system but which were recorded as if they had been made by a user"
[4] >In April 2003, Horizon version S30 was released by Fujitsu. It had not been properly tested, and it introduced a bug known as the Reversal bug. If a Subpostmaster inputted a series of transactions, and then for some reason wanted to cancel them, the transactions would have to be reversed out of Horizon. The Reversal bug appeared to reverse a transaction, but in fact doubled it. This was due to a plus sign in the code which should have been a minus sign. The Reversal bug was discovered by Fujitsu after Subpostmasters began to complain about the growing amount of non-existent money Horizon calculated as being in their accounts at the end of the week. When one Subpostmaster reversed an internal £13,910 cash transfer out of one stock unit and into another, he managed to create a £27,820 negative discrepancy in his accounts.”
[5] > "The biggest problem, however, was the information being written to something called a message store.” >“According to Clint, Horizon’s developers had spent the last couple of years ‘firing any old shit’ into the message store as they changed and developed the product. Clint explained that this was a recipe for disaster. If a message was given a new data field, but this wasn’t retrospectively applied, the counter software could retrieve an old message with what it would now perceive to be a missing data field. The reaction of the application would be unpredictable.”
Were bugs actually involved? I could only find this sentence in the article and it leaves it open if it was a bug or an user error.
>Many of the Hertz cases involved customers who had called to extend their rental agreement, but the extensions were not properly reflected in Hertz's computer systems.
Even when these code snippets are cherry-picked they tell enough about their review practices.
>have some highly atypical needs that we here on HN don't understand.
Somebody else checked in another thread. You can use unary minus in VBA.
[1] >One member of the development team, David McDonnell, who had worked on the Epos system side of the project, told the inquiry that “of eight [people] in the development team, two were very good, another two were mediocre but we could work with them, and then there were probably three or four who just weren’t up to it and weren’t capable of producing professional code”.
They did not care about data integrity and schema migration. It's probably the most incompetent thing one can do when working with data in such a system.
That's why we define database schemas, or write protobuf schemas, or avro schemas, and parse JSON data in the frontend with zod.
As a rule of thumb you don't even just change the datatype of a field and hope it works. You introduce a new field and migrate over the course step by step from the old field to the new field, i.e. you write the data into two fields, and read the data from the new field or fallback to the old field.
Actually their use of the Riposte message system in 1999 was not that different in what we use today in many cloud-based systems with microservices.
Also my experience.
Only using Gradle deamon does not help making a multi-project setup much faster. You also have to enable build cache, configuration cache and configure on demand with `--configuration-cache --configure-on-demand` and hope nobody in the project breaks the ability for Gradle to use these caches. But then it still took at least 10 seconds to build and start my services (and that's with incremental builds, like you changed one line of code after the first slow build). I spend two days and more after release to speed this stuff up, before it was 30 seconds sometimes 60 seconds.
And the protobuf Gradle plugin sometimes did not update the generated code, so you had force-delete the files on every build. And then other stuff in the caches broke and you had to delete `.gradle` directory and sometimes even the `~/.gradle` directory. And sometimes the Gralde daemon hangs so you have to force it to stop with `--stop.
Go build, deno and bun are so much more reliable and faster. Something that was surprisingly fast was using the Gradle setup with skaffolding. Java hot code swapping is very fast.
I first thought it's just a backend use-case, where processing 1000 records in a paginated result is common, but the parent mentions "rails", so it sounds like a frontend use-case.
gomponents is amazing! I find the abstractions just right. it now looks possible that I can port my minimalistic bun/deno setup with htmx to go.
I found "gow" watcher that allows auto-restart of the development webserver when go code was changed. And I'm using "hx-refresh" header paramter and "hx-trigger='every 250ms'" to have a simple polling browser refresh.
it also integrates well with tailwind css. you can use tailwind vscode extension and define a custom "classRegex" for gomponents "Class(...)" function.
I needed to write a custom `Classes()` function that allows me to have conditional classes like `clsx()`. it's a bit hacky, but I like the simplicity.
func Classes(nodes ...g.Node) g.Node {
var classes []string
for _, node := range nodes {
if node != nil {
var builder strings.Builder
_ = node.Render(&builder)
c := builder.String()
c = strings.TrimLeft(c, " class=\"")
c = strings.TrimRight(c, "\"")
classes = append(classes, c)
}
}
return Class(strings.Join(classes, " "))
}
the runtime panics for functions that use vararg for optional arguments and have an invalid number of arguments is probably an okayish trade-off. mixing attributes and children elements in the builder functions, I don't know if it's good or bad, but I like the simplicity; JSX and hyperscript-like functions separate tag, attributes, and children into three different parameters.edit: reformat and typos.
>What is the benefit of Tailwind anyway?
I'm prototyping design systems using Tailwind which saves me some minutes of work every day. It also uses just a CDN script that I directly load in the browser, no bundling required. I have an empty "tailwind.config.js" in the root directory in order to use the Tailwind language service.
It's interesting how much of a component system one can build only by using `<input>`, `<label>`, and `<form>`. For the remaining interactive elements that can't be build easily without JavaScript I plan to use Web Components.
For me this is a reasonable 80-percent solution. But for web applications with high requirements I would use React and React-Aria components/hooks.
I understand that Node is mostly known as a frontend tool and Rails uses it for that, but as far as I remember Node was as least initially developed to bring JavaScript runtime to backends.
Even without a package manager node is just a node.exe under Windows, and I think you just have to download and unpack npm and then put node and npm into your PATH environment variable.