Hacker Newsnew | past | comments | ask | show | jobs | submit | cdtwoaway's commentslogin

ELI Beamlines | Data Management Specialist, CS Engineers| Prague, Czech Republic | ONSITE, VISA

ELI Beamlines is a European Petawatt laser research facility where an international team currently installs the world’s most intense laser systems.

We are in the middle of commissioning and getting our first users and producing data - and now we have to start handling that. Currently, we are building our first storage system (PB-range), and facing challenges regarding high-throughput applications, cataloguing / metadata of complex scientific data, integration of computational infrastructure, integration into the grid and with off-site data centers,..

We're building a small team for that, and I'm looking for well-rounded, hands-on personalities who can both implement solutions for sometimes quite challenging applications, but also work with different scientific stakeholders to negotiate tradeoffs and policies.

https://www.eli-beams.eu/en/careers/scientific/scientific-da...

The profile is intentionally a big vague because I can fill 2-3 roles (and a couple of more in the CS department)- and if the profile fits, create new ones. I can also see someone working closer to the DAQ chain or the e-infrastructure side.

Also (not so related to HN, but why not try): I'm always looking for LabVIEW and PLC developers.. https://www.eli-beams.eu/en/careers/technical/labview-develo... https://www.eli-beams.eu/kariera/technicke-pozice/control-sy...


Nope. ECUs have something called a "fault memory" where the last n detected errors are stored, and that can be recovered. This is actually what workshops use for diagnosing a car.

This can give lots of information about what happened (faults could be "didn't receive message xyz" "sensor xyz gave signal out of tolerance"). But there is definitely no system trace for the communication - too many messages to really store them I guess.


Yeah, firmware is another issue. You read and flash firmware or parameters often directly over that CAN bus. There is nothing to validate that, for one manufacturer, I needed passwords (casually handed out to every supplier, the same for every unit), for one, the "encryption" was a XOR with the same number that had been used for every model for years. I didn't know why they even bothered. One of the manufacturers at least stopped you from flashing new software to an ECU more than 3 times.

Did I mention that we had incredibly high fluctuation (at least production line test benches - brutal deadlines and 2am deployments, working in loud production halls, lots of travel, no technical innovation,..). We basically hired anyone who was alive and somewhat skilled. I don't think anybody ever talked to me about security - ever.

What these articles are showing, is amateurs' work. I'm terrified by the idea of what a disgruntled / crazy / .. person with experience in the field could do.


Not surprised. I built automotive test benches for some time. The moment you have something that can remote-access the CAN-bus, you have a problem.

There are typically only a few busses in a car. In many cases, there is a LIN bus for entertainment / radio / lights etc that is physically separated from the main CAN bus. This one is mostly harmless.

But if you can somehow talk to the main bus... There are like 5 critical ECUs that have to communicate "I'm OK" (engine, breaks etc) - otherwise nothing works. Those communicate with some minor encryption, and that communication is somewhat validated (they send counters to each other etc). But it doesn't matter. First of all, the protocols and databases are similar for different models, and known to A LOT of people who had jobs similar to mine. In order to test or build any ECU, you have to simulate the correct communication, otherwise the ECU won't start up.. Second, just sending nonsense with the right identifier could probably shut down the car or at least make it think there is a major problem. Third, there are messages that simulate power-cycling the bus..


Scary stuff. We connected light bulbs to the internet so people could turn them on and off with their phones, and they were hacked and turned into a botnet[1]. Okay, fine, maybe your "smart" bulbs blink or burn out, and you replace them with "dumb" bulbs.

Why, exactly, do people think it's a good idea to connect cars' engines to the internet? If something is exposed to hostile input, it will eventually be hacked, and if there are 100,000 identical things out there, they will all be hacked at once. Unfortunately, I think it will take something like all Teslas accelerating uncontrollably off the road, because some teenager was bored, for people to get it.

[1] https://www.techdirt.com/articles/20161107/09211835982/not-e...


All governments are essentially mandating connected cars effective 2020 model year.

As hybrid and electrics take root, mileage and location based metering/taxation will become a major revenue source.


In the past, requirements for new cars were not retroactively applied to previous year models. Are you saying that is/will be changing?


My guess is that in a decade you’ll be using an OBD device for time and distance based metering, or pay a heavy surcharge for LPR based location only systems.

Transponder systems like EZPass have a business model too expensive to scale.


If the LIN bus can access lights, and is bundled up with IMHO unrelated systems like radio/entertainment then that seems wrong by design. I say this as if somebody can remotely control your lights on a car, that in itself at the wrong time could and would prove dangerous.


Lights for instrumentation (inside the car). At least on the systems I worked with. I'm not much of an expert on that bus.

Well, messing with this bus (audio volume.. blinking displays etc) could be disruptive as well, but not as critical as killing the engine.


I had a read up upon LIN https://en.wikipedia.org/wiki/Local_Interconnect_Network

Was introduced as a cheaper alternative to CAN, and to be used for non-critical aspects of cars (intended). Though seat controls are listed as common use for it. Which with some occupants and cars with the seatbelt - would enable the seat to pull the driver away from the controls. So whilst not directly deemed critical - certainly a vector of concern in some permutations of seat/driver position (thinking large 4x4's driven by small people who end up having the seat fully forward and raised, as an example).

My initial concern was the main lights, though as you cleared that up to just internal lighting - that again could prove a problem as dark roads, a sudden change in internal lighting would from internal glare reduce visibility.

Biggest take away is that the LIN bus has no form of encryption and the only verification would be checksums upon the data packet.

I'm sure we will read more about LIN over the years as the ability for car makers to cut-corners is not unheard of and as LIN is cheaper to implement than CAM, can see how that may well play out.


>Though seat controls are listed as common use for it. Which with some occupants and cars with the seatbelt - would enable the seat to pull the driver away from the controls. So whilst not directly deemed critical - certainly a vector of concern in some permutations of seat/driver position (thinking large 4x4's driven by small people who end up having the seat fully forward and raised, as an example).

Combine seat adjustment with GPS position reporting and you could devise a way to make a targeted person lose control, without taking control of "critical" systems, exactly as they're crossing a bridge.

Suddenly I feel the urge to Faraday-cage my car.


I expect we will see that in a movie/thriller next year


I work in one of the big 3's there is significant push to physically isolate all the CAN buses. The guys that hacked into Jeep were ex-NSA and worked on the hack for more than a year to get it to work. I'm not saying cars are 100% secure, but this sort of attack will take crazy effort and maybe physical access to the car.


Hey that's interesting, most of these devices IIRC work via the OBD port with an additional cutoff wiring. I haven't looked but I'm assuming the OBD port is somewhat restricted?


Really depends on the vehicle. Some will have broadcast traffic that is easier to spoof, and ride on CAN addresses that aren't reserved for OBD. OBD quite often rides on the main CAN network, and without a gateway any ECU can be queried. The secondary CAN network (if the vehicle has one) is also on the OBD plug but on different pins.


Yip. And if you can query any ECU, and know what you are doing/have more information on the system, you can get higher level security access (and that information, is again, not THAT hard to find). This allows you to call functions that modify the parameters and probably restart it as well..


Precisely. It's also interesting to see what you can do with vehicles where the broadcast traffic 'leaks' out the OBD port. A lot of makes use the same ECU across models for common parts.


It would be simple to have hardware that can only use the K-line (which is diagnostic only) or even only uses power from the OBD2 connector.

But you could also design your hardware to be able to write messages on the CAN bus and/or be able to take the bus down.


Literally: I have successfully sent CAN messages that were understandable to ECUs with an Arduino while waiting for a delivery of real hardware. There are Arduino-GSM shields that are super easy to use and would be remote-accessible.

Such a device would be dead easy to build even for someone who has almost no experience in electronics.


You can also buy plenty of development boards with an ESP32 and a CAN transceiver. Small, fully programmable, with Wifi and BLE, for less than $50.


Defaulting to OS language can be terrible for organizations where the working language is different than a local language. Lots of programs do it and they always default to the language the OS was installed in, not the one that is currently used by the user.

I work in an international organization in Czech. The local IT team installs Windows in the local language, then sets it to English (which is fine, mostly). Half of our employees don't speak Czech well and changing weird tools to English is a constant and difficult hassle for those who haven't learned the basic words yet (printer drivers and small open source tools are the worst).

Browser language can be difficult as well. Half of the population is bi- or multilingual.. choosing which language to use for a browser (for me: German or English) affects how well Google Translate works - which I use daily. (Somehow, big American companies don't get the idea that people can live in multiple countries at the same time or speak multiple languages).


> I work in an international organization in Czech. The local IT team installs Windows in the local language, then sets it to English

That doesn't make sense. If the OS is "set to English", how do programs know to run in Czech?

Anyway, we just install Windows in English. (British English, so the dates appear the right way around and there's a chance of metric measurements.)


User / Domain profiles that set the language of wherever you login. The "original" installation remains in Czech.

Yes, it would be preferable to have the installations in English initially. But we weren't always international and not all of our employees speak English well (this is common for older people - former UDSSR ..., admin staff and people in roles that don't require a college education). There are still legacy tools in Czech, fully Czech teams (who obviously work partially in their native language), a need to work in the local language (procurement, legal topics,..) etc. It's just not economic to completely enforce English.


just FYI Czechia was never part of USSR and it's quite offensive to tell it to Czech person after being occupied for decades by Soviet military. that's like saying Afghanistan and Iraq are US states to people living there, just because US occupied their country


You are correct, I was sloppy writing that and apologize.

Growing up, I learned that Czechoslovakia was part of the "Eastern Bloc" and we were never taught much about the individual countries and their peoples. Moving there taught me a lot more about the country and its neighbors' history and culture, and also my own culture.

Although I'm not sure about "Central Europe".


it all comes down where you think Vienna it's, because it's for sure more eastern city than Prague, but i don't see people calling Austria eastern European country, which is political from before 1989

i have no problem ignoring central Europe when people will be consistent about geography especially regarding Austria, but since nobody it's putting Austria in eastern Europe then we have to live with Central Europe, after all Europe ends at Ural, so calling Czechia eastern Europe it's quite a stretch


> Although I'm not sure about "Central Europe".

This term predates the Iron Curtain.


Changing browser language settings is a couple clicks. Are your systems not user configurable or something?


people can live in multiple countries at the same time

As a silly American, can you explain how you live in multiple countries at the same time? Do you mean you, for example, live in one country and work in another?


This is a favorite topic of mine. There are several multi-country metropolitan areas in Europe, for example Malmo-Copenhagen and Görlitz/Zgorzelec. Many cities have smaller suburb cities across the border, like Strasbourg-Kehl and Geneva-Annemasse. And the Benelux countries take this to the extreme, of course.

Even Berlin, which is pretty far from the Polish border, have commuter trains to Poland. That's right, the Berlin metro ticket will take you to Poland.


I live in Spain and Switzerland. I spend most of the summer in Spain, and the rest in Switzerland. I work 100% remotely, so I can live and work anywhere (not seamlessly, as I need visas and residency permits and everything else, but still doable).

My wife is a scientist, so we travel a lot and change places of living. So far, I lived in Russia, Switzerland, Italy, Spain and Denmark, and about 2 months in the US.


As a young adult, I studied in a country (had a flatshare there) and took the train (2hrs) at the weekend and during the holidays to stay with my parents. I guess lots of people close to borders know family situations like that (parents, partners).

Now, I have a job with 90% business travel between two countries (but same cities). Have small apartments in both. It is just more economical and comfortable that hotel room living.

There are also often reasons not to completely move to a country, even if it's close (different tax situation, having to switch social security systems which affects your retirement, wanting to stay inside a certain social security systems which requires a place of residence..)


you can live in Bratislava which it's less than hour drive from Vienna where you can work every workday, plenty of people in Europe live nearby border and spend lot of the time on both sides speaking completely different languages


Working at CERN is one example


If you are a very experienced programmer, you program LabVIEW (one of the major visual languages) almost exclusively with the keyboard (QuickDrop).

Let me show you an example (gif) I press "Ctrl + space" to open QuickDrop, type "irf" (a short cut I defined myself) and Enter, and this automatically drops a code snippet that creates a data structure for an image, and reads an image file.

https://github.com/b-ploetzeneder/MachineVisionCodeSnippets/...

If you are efficient at this type of input, the "dragging/dropping/rearranging" is similar to refactoring that you would do in an IDE.

The only difference is that there is something called secondary notation in many visual languages (people are not aware of that, I'm only familiar with it because I've done research on the topic - it is how the code is visually arranged). How code is arranged is kind of a quality parameter for visual code (google examples for "spagetti code"). There are typical patterns that are instantly recognizable to an experienced user, ways of using distance and direction to group connected parts..

I actually played with alternative forms of input for LabVIEW, mainly gesture control and "drawing" on tablets. It sounds like a fantastic idea, but only for 5 mintues. After that, your hands start to hurt. The reality is that keyboard and mouse are heavily optimized tools for input (minimal movement of fingers, and we have lots of muscle memory), and don't restrict you. It's like saying "I can type xxx word per minutes" and thinking that typing faster would help you code faster..


I totally agree with you & thanks for that nice GIF! I used LabVIEW a lot and always enjoyed it... so anyway we have keyboard input for the diagrams / blocks, its very important. also a minimum of wires, they are annoying to draw


Agreed. We (engineering department in a medium scale scientific facility) use 3D printing for rapid prototyping and as temporary solutions.

Quite often, people walk into my office and need data acquisition /measurement / control solutions for completely random problems. Quite often, that requires me to build solutions to mount sensors/actuators to random equipment, or I want to pack everything into a neat box. For this, 3D printing is ideal (we have a Stratasys printer). The inhouse metal workshop is too slow (and requires more sophisticatated drwings), 3D printing can deliver within hours.. and I can iteratively change things. I don't use sophisticated tools, software like Google Sketchup is trivial to use.

Still. 3D printed solutions are rarely permanent. The durability is limited and cleanliness is an issue (the surface quality is bad, and I'm worried about outgassing). So in the end, I end up replacing most parts with aluminium & steel. I have thought about "3D printed metal" (shapeways etc) as a second step, but haven't tried that yet.


I've started experimenting with 3D printed ceramics (on the Form2). It seems like a useful material for a number of applications (less thermal expansion than the resins, and less than aluminium).

Firing is a pain, and you need to compensate for shrinkage. But it could be interesting.


They are building one of those betatrons in Petawatt in Czech Republic - ELI Beamlines project.


Happy to see another LV user here.

Organization gets much, much easier once you get the big architecture concepts - produce/consumer patterns, messenger-queues, event structures, actor framework. Yes, it can be painful, but the newer functionalities (clean-up, riddiculously easy sub-vi creation,..) subtly improve it.

Btw: If you are using LabVIEW and have never used Quickdrop, try it. It is the most underutilized and amazing feature.


Will try to attend.


Consider applying for YC's Summer 2026 batch! Applications are open till May 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: