These da Vinci style drawings were likely created using the SketchUp models from sometime ago, which you can download from the page below to play with:
Readit Newsamadio commented on CERN Council reviews feasibility study for a next-generation collider home.cern/news/press-rele... · Posted by u/elashri
What experiments would people like to do, that this new collider would make possible? What theories will be tested?
If you would like to know more details about the physics case for FCC, there was an academic training recently at CERN:
Deleted Comment
amadio commented on Reproducible C++ builds by logging Git hashes jgarby.uk/posts/git_repr/... · Posted by u/j4cobgarby
For those of you using CMake, have a look at the module below:
https://github.com/xrootd/xrootd/blob/master/cmake/XRootDVer...
and also the genversion.sh script at the top of the repo.
I use these plus #cmakedefine and git tags to manage the project version without having to do it via commits.
At CERN, software stacks are created centrally and software distribution for experiments is done with CVMFS (https://cernvm.cern.ch/fs/), an HTTP-based read-only FUSE filesystem.
EESSI (https://eessi.io) has taken this model further by using CVMFS, Gentoo Prefix (https://prefix.gentoo.org), and EasyBuild to create full HPC environments for various architectures.
CVMFS also has a docker driver to allow only used parts of a container image to be fetched on demand, which is very good for cases in which only a small part of a fat image is used in a job. EESSI has some documentation about it here: https://www.eessi.io/docs/tutorial/containers/
amadio commented on First ever website created is still online info.cern.ch/hypertext/WW... · Posted by u/kathir05
For those interested, there's more information here:
https://home.cern/science/computing/birth-web
If you come to CERN, you can also see the NeXT machine that was the first web server.
amadio commented on An intro to DeepSeek's distributed file system maknee.github.io/blog/202... · Posted by u/sebg
I thought they used ceph too. But I started looking around and it seems like they have switched to CernVM-FS and in house solution. I'm not sure what changed.
CERN is a heavy user of ceph, with about 100PB of data across cephfs, object stores (used as backend for S3), and block storage (mostly for storage for VMs). CVMFS (https://cernvm.cern.ch/fs/) is used to distribute the software stacks used by LHC experiments across the WLCG (Worldwide LHC Computing Grid), and is back by S3 with ceph for its storage needs. Physics data, however, is stored on EOS (https://eos.web.cern.ch) and CERN just recently crossed the 1EB mark of raw disk storage managed by EOS. EOS is also used as the storage solution for CERNBox (https://cernbox.web.cern.ch/), which holds user data. Data analyses use ROOT and read the data remotely from EOS using XRootD (https://github.com/xrootd/xrootd), as EOS is itself based on XRootD. XRootD is very efficient to read data across the network compared to other solutions. It is also used by other experiments beyond high energy physics, for example by LSST in its clustered database called Qserv (https://qserv.lsst.io).
amadio commented on The Pain That Is GitHub Actions feldera.com/blog/the-pain... · Posted by u/qianli_cs
Already see people saying GitLab is better: yes it is, but it also sucks in different ways.
After years of dealing with this (first Jenkins, then GitLab, then GitHub), my takeaway is:
* Write as much CI logic as possible in your own code. Does not really matter what you use (shell scripts, make, just, doit, mage, whatever) as long as it is proper, maintainable code.
* Invest time that your pipelines can run locally on a developer machine as well (as much as possible at least), otherwise testing/debugging pipelines becomes a nightmare.
* Avoid YAML as much as possible, period.
* Don't bind yourself to some fancy new VC-financed thing that will solve CI once and for all but needs to get monetized eventually (see: earthly, dagger, etc.)
* Always use your own runners, on-premise if possible
I think this is good advice overall. I wrote a CMake script that does most of the heavy lifting for XRootD (see https://news.ycombinator.com/item?id=39657703). The CI is then a couple of lines, one to install the dependencies using the packaging tools, and another one calling that script. So don't underestimate the convenience that packaging can give you when installing dependencies.
I was just taking a look and couldn't help but notice the switch statement for your operator[], which likely causes a lot of unnecessary bad speculation at runtime:
https://github.com/RandyGaul/cute_headers/blob/755849fc2819d...
I fixed this exact problem in a highly used library in high energy physics:
https://gitlab.cern.ch/CLHEP/CLHEP/-/commit/5f20daf0cae91179...
Many believe the C++ compiler will magically optimize the switch away, but in some cases, like the example above for CLHEP, it doesn't happen, so you end up with bad performance.
Since you left this "optimize me" comment here:
https://github.com/RandyGaul/cute_headers/blob/755849fc2819d...
See an optimized quaternion multiplication implementation in SSE by me here:
https://stackoverflow.com/questions/18542894/how-to-multiply...
https://twiki.cern.ch/twiki/bin/view/CMSPublic/SketchUpCMS