The most effective solution I found for pigeons (although I haven't built this so can't compare...) is feeding them at regular times. It doesn't even have to be a lot. They're smart enough to know I come out around 0830 to give them some seed, and then they fly away for the rest of the day because no more food is coming. Sometimes when new babies appear, it takes a couple of weeks for them to copy the pattern though.
If you live in an urban area, please don't do this. Pigeons are pests. They carry diseases. Their shit is toxic and can cause serious respiratory issues.
I think your second paragraph there is the critical point that large companies (including the one I work at) miss or purposefully ignore: let the employee control when (and how many) days they are in. Cohesive teams will self organise something suitable for their productivity, non-cohesive teams won't get any better by frustrating x % of the members. But, fundamentally, large companies simply lack trust in their employees so do not want to allow this.
Also, they have a lot of real estate costs to justify. Nothing like physical tech debt for anchoring your company in the past.
Doesn't the data in that blog show Apple improving faster than MicroSoft? Going from taking longer than to fix bugs in 2019 to being faster than them now?
It's pretty impressive that everyone seems to have reduced their time to fix bugs. Linux is doing an amazing job there.
Generally trying to debug optimised code is a nightmare anyway. Most debugging is performed on non-optimised builds, which wouldn’t be affected by the proposed optimisation.
There's actually a compiler that does all these things and allows debugging of optimised code whilst seeing the unoptimised form - Sulong.
Sulong is an LLVM JIT-compiling engine that runs on GraalVM. So it uses the same infrastructure of the JVM, but without JVM bytecode getting into the picture. Instead the JVM runs LLVM bitcode directly. But it does so in the standard way which gives many benefits:
• Splitting of hot/cold paths, as in this work.
• Cross-function optimisation and inlining regardless of visibility, as requested above.
• Ability to debug an optimised program, because the JVM can 'deoptimize' the parts being inspected or debugged.
• Run the Linux version of the bitcode cross-platform.
• In "Managed Sulong" (which is an enhanced payware version), all allocations are garbage collected and bounds checked. Yes even for C/C++ programs, just needing a recompile. It's just about possible to do this within the rules of well defined C/C++, as long as the program doesn't try to do non-portable or non-defined things like pass stack pointers between threads. Managed Sulong can also sandbox LLVM code modules, and redirect IO back into the JVM for mapping via the pluggable socket/filesystem layers.
• Cross-language interop, including recent experimental support for e.g. casting Java or Ruby or Python objects to C++ objects and calling methods on them.
• All the same compiler optimisations as LLVM does still apply.
It's a pretty amazing and under-appreciated project. On the other hand the code being run inherits the limits of the JVM, e.g. you shouldn't try and fork the process (of course, lots of runtimes don't like being forked and on Windows you can't do it at all).
Fascinating to see other possibilities that were out there. Were the capabilities in Hydra the inspiration for what Fuchsia OS has, or are they a long standing concept?
Hydra and Fuchsia are both operating systems that use Capability-based security. Hydra would have been one of the very earliest ones, while Fuchsia is a very new one. There have been many others in between, like KeyKOS or EROS, as well as use of capabilities in "normal" operating systems, like FreeBSD's Capsicum, or arguably even just passing file descriptors over Unix sockets with SCM_RIGHTS on any POSIX system. There have also been capability-based programming languages like E and Pony, and capability-based network protocols like CapTP or (my own) Cap'n Proto. So it's unlikely that the designers of Fuchsia directly based it on Hydra, but there was probably indirect inspiration, yes.
Just to make a vast generalisation with no hard evidence: I wouldn’t be surprised if it often came down to age. When I was younger, I had the desire, and more importantly the time, to keep everything I used as open source as I could afford.
Fast forward a decade (or maybe 2) and while I am still very pro open-all-the-things, I am happy to pay more for a controlled environment to run things I rely on but don’t care to spend time on maintaining and configuring.
The signup form refuses to allow you to register for a ticket unless you check the “allow us to send spam” check box. That really doesn’t inspire confidence in the quality of the conference.
Most of the services I use allow it without a phone number (as SMS isn’t very secure). A bigger service that I can think of off the top of my head is GitHub.
