Don't know if birds count, but the egret population has exploded in the UK in the last 10 years.
There's zoos here that have them in their exotic bird sections. Always makes me smile as they are often visible even in London parks and rivers.
535 karma · joined April 14, 2023
There's zoos here that have them in their exotic bird sections. Always makes me smile as they are often visible even in London parks and rivers.
It will always have a special heart too.
However, in the way it was used in my roles at least - I found it enforced far too rigid a separation between the data and the presentation.
There were multiple times a backend could not perform some function or transformation of the data, for various and always non technical reasons.
That left it to the xslt developers to figure out a solution, and sometimes due to the limits of the language that involved writing a custom java function / xslt plugin.
Things that were incredibly simple when some sort of scripting language is available in your frontend web app could be incredibly convoluted when all you had was an xslt processor.
There's probably a lesson in there somewhere.
If you're unaware, the FSH lays out some guidelines a lot of distros follow - /usr/bin is a good place for any executable coming from a package in my book.
Agree debuild can be opaque as it is really a wrapper around loads of dpkg-* scripts. Digging further into those helps but it's not obvious.
WRT git, I find it useful to get the entire repo as a tar.gz and treat it like an upstream source package. The have the Debian build stuff as a process on top of that.
This is how many packages are maintained for real in the distro (i.e. imagine being the package maintainer of redis or vim and do it that way). It kind of makes sense to me to follow the pattern as things are geared up for it.
The guide I linked to used to be linked to from the main docs page I believe - I went to double check and it now has this more recent guide linked instead - it seems equally thorough.
https://www.debian.org/doc/manuals/debmake-doc/
These guides were sufficient for me to learn packaging pretty complex Debian projects, and are linked to from the docs home page on the Debian site. Guess that's all I'm saying.
The format of the .deb package itself is also pretty simple and straightforward.
But historically and probably now even almost all packages were nothing like this.
When you need to target particular shared libs as dependencies and link against them, confirming that via build isolation, etc - which is what the vast majority of packages have to do - then all the other complex tools become a necessity.
To be honest I found it an incredibly comprehensive overview of Debian packaging, all the way up to using pbuilder to ensure dependencies and sandboxed builds, onto lintian to assess the quality of the artifacts.
https://www.debian.org/doc/manuals/maint-guide/
Building complex Debian packages is time consuming with a lot to learn, but to be honest I don't remember having many issues with this guide when I started out.
Loads of sites like this submitted, what's is the motivation I wonder?
Often times using things like cucumber to describe a set of interactions, in the days before headless chrome it'd drive selenium which would literally open Firefox on your desktop and start navigating the site.
It did it's job but the feedback loop was slow.
Today I mainly write libraries, cli tools and the occasional small HTTP API. I still have unit and integration tests but they are all just standard pytest functions. I can run each type individually, my definition of an "integration" test is either something that talks to the outside world in some capacity, or something that is really slow (mostly running an ml model these days).
I much prefer today's approach, but admittedly I work on things with far fewer points of interaction which I think greatly simplifies the work.
I understand what the OP is saying but not sure they get this context.
If I were working in that world still I might have that single binary, and a script, but I'm old school and would probably make an RPM package and add a systemd unit file and some log rotate configs too!
So CUDA gets packaged up in the container twice unless I start building everything from source or messing about with RPATHs!
What is killing me at the moment is deploying Docker based AI applications.
The CUDA base images come in at several GB to start with, then typically a whole host of python dependencies will be added with things like pytorch adding almost a GB of binaries.
Typically the application code is tiny as it's usually just python, but then you have the ML model itself. These can be many GB too, so you need to decide whether to add it to the image or mount it as a volume, regardless it needs to make it's way onto the deployment target.
I'm currently delivering double digit GB docker images to different parts of my organisation which raises eyebrows. I'm not sure a way around it though, it's less a docker problem and more an AI / CUDA issue.
Docker fits current workflows but I can't help feeling having custom VM images for this type of thing would be more efficient.
Even here in Europe salaries can match Doctors and Lawyers but the barrier to entry is much lower and in my experience employment is still based on merit more than anything.
Perhaps there's some element of "don't rock the boat" but maybe some guilt too. We really have lucked out.
Not sure how comfortable I'd feel taking union action over my job that requires me to leave the house once a week but pays 3x a teachers salary.
I'm talking about a time when investment in browser development and web standards was so lacking that being able to achieve things like this blew everyone's mind:
https://meyerweb.com/eric/css/edge/menus/demo.html
Hackernews, were it around back then, would've gone as crazy for this post as we do the latest AI model today.
I was last a "web developer" almost two decades ago, but dipping back in on a few occasions I am always appreciative of how much innovation has happened since then.
The world before the huge investment in browser technology was dark. Tables and spacers for meaningful layout and flash or shockwave for anything interactive.
I remember a time when css based drop down menus were seen as some sort of state of the art.
Except the dream includes first using a tech salary to pay off a mortgage or at least most of it, and then being able to comfortably work with my hands in some romantic artisanal manner.
AI probably gets me closer to spending 60 hours a week doing back breaking groundwork and struggling to pay the bills.
I've always felt my real education in software engineering started at work.
20 odd years later I lead a large engineering team and see the same with a lot of graduates we hire. There's a few exceptions but most are as clueless as I was at that age.
I would think even in small scale having things like a 3d printers, CNC machines, networked video surveillance and alarm systems, solar arrays etc would be very beneficial.
Absolutely though the top priorities would be much simpler things though like food, clean water and shelter.
I really only know a handful of people with desktops and they are all gamers. My office is devoid of them aside a few specialist workstations.
On the way learned a lot about bit manipulation and reading ISO type specifications.
128 cores going 100% in htop was fun!
Hopefully we kept them well. We had them for years and in that time they spawned regularly, ended up giving our original pair up for adoption when we moved house.
Tank was smaller than 40g. You're right though bigger is better, that's the general advice with all pets (including goldfish which can grow huge!).
Having kept them before, they are genuinely about as hard to care for as goldfish but need bigger tanks and a little bit more cleaning.
Also super easy to breed, we let the spawn hatch once and ended up with about 70 larvae, they cannibalize quickly but 6 grew to full size and we sold them on very easily.