3,469 karma · joined February 28, 2013
Brotzeit is regional for a mid-day meal (10am-5pm?), with Imbiss and Vesper other alternatives. Those three can also be "taken with you" ("eine Brotzeit/einen Imbiss/eine Vesper mitnehmen") when leaving your house to be consumed during (e.g.) a day trip.
Given that this is apparently possible, there should be no problems with a 1000% carbon tax on non-electric planes starting tomorrow, right?
This is a lie. Plenty of suggestions have been made from this part of the political spectrum which are primarily based on incentivizing less damaging behaviour. The problem is that while we can reduce flying and we can reduce trips by car and we can reduce meat consumption and we can force shipping companies to use more environmentally friendly albeit more expensive fuels, none of the "technological solutions" you and other people say "should be developed" exist at the moment. By all means, feel free to invent new technologies which reduce carbon footprints and which help tackle climate change, but stop saying that really someone should develop these things so that maybe they could be used twenty years from now.
Twenty years ago, we had the option of either drastically raising taxes on CO2 or trusting that "technology" would arrive to reduce CO2 footprints. We were promised exclusively electric cars everywhere by 2020, passively cooled and heated housing etc. etc. None of those things have materialised, instead now we have people saying that we should "improve technology" and maybe in twenty years time we will have some solutions.
We really need to start acting now.
Updating is a bit annoying as there are no Debian packages and one has to essentially re-install from scratch on each update, but everything else is working perfectly well. Categorising expenses allows for easy monthly reports on shared expenses, too.
When defaulting the spaceship operator, the same happens for C++ (by comparing members). In this special case, the equality operator is also effectively defaulted, so as described in the article
struct A {
…
auto operator<=>(A const& rhs) const = default;
};
gives you automatic member-wise comparison "derived" by the compiler.This is a feature, not a bug. Nobody actually wants to rely on a single entity (for or non-profit) for their communication. Nobody wants to be stuck in crappy Electron and mobile clients.
I had some hope that Matrix may be able to alleviate those concerns and provide a modern, federated chat solutions. Unfortunately their quality of implementation seems to be rather low with slow, laggy and resource-hungry clients and ridiculously resource-hungry servers and their current setup still apparently include a single "identity server".
* They may be high but motorists still pay less in taxes than the general public contributes to the upkeep of their infrastructure, even when excluding externalised costs (healthcare, climate change accommodation etc).
* The same is true for e.g. New York, whereas (e.g.) London has a fair amount of low-density housing. Not quite sure how this is an argument if the vast majority of space in cities is still reserved for cars (either parking or driving).
I had two drivers within the last 12 hours taking my right of way by illegally driving onto a cycle path when turning from a side street into a main street.
Both claimed that they couldn't see into the main street if they didn't drive over the cycle path first, but somehow while both of them were perfectly happy taking cyclists right of way, they did not want to take other motorists right of way by driving directly onto the main street.
Hu? Of course the jobs of people working at ICO etc are slightly safer if more criminal activity happens, but office workers at ICO do not get that money. It goes to the treasury and hence, by extension, the British public.
> The people who had there data stolen, are now on a register sold to the insurance industry, and the insurance industry decides they are a greater risk to insure, so the costs to the consumer go up. Strange how crime really drives the economy.
The fine punishing a criminal activity nearly nowhere goes to the actual victim of the crime, the victim is instead compensated in a second payment. Of course it would be nice if in addition to this fine, some kind of blanket compensation mechanism (e.g. 1000€ per datum per person) would be installed.
My toolkit is maybe a bit non-standard in that it has attracted a few external collaborators using it as well and I like to think I have taken better care of upholding coding standards, documentation etc.
Normally software in my field is kept within a group and dies after one or two PhD students have left.
To be clear, I can understand that a PhD candidacy justifies a temporary contract and I'm not even asking for a permanent position directly after a PhD (as would be standard in industry), I'm only asking for a reasonably safe perspective towards a permanent position reasonably soon after graduating. Can't exactly start a family if you don't have any kind of job security beyond the next couple months.
> You said "making this e-mail address public" in your question - it's worth noting that binding a 3PID does not publish it in a public list; instead, it means it can be used as a key to look up your MXID for users who already know your email address.
The domain part of e-mail addresses is public anyways due to certificate transparency, meaning that an interested party would only have to enumerate the local part to find all e-mail addresses from a specific domain used by Matrix users. In this respect, the lookup answers the question "Does this address exist?" and as such makes it public.
> If you don't specify an email address, you won't be able to reset your password. Are you sure?
In your response on pg. 4, you say:
> Commented [11]: Yup, this is the point of the service -to map email addresses and phone numbers to matrix IDs.
Is it possible to specify an e-mail address to be able to reset passwords without making this e-mail address public? Clearly, this should be the default setting if someone enters an e-mail address after the above prompt by Riot.
Given that the GP personally regretted the end of ICE cars, it seems not unreasonable to ask about their other feelings as well?
However, just because it is (like most build system questions) outside the scope of the standard does not mean that it isn’t possible to define some project-internal rules about what gets compiled and linked into what and that the build system cannot apply those rules to take work away from users.
The few external dependencies my project has are installed semiautomatically before any compilation starts.
That is, I have a bunch of .cpp files which need to be compiled into individual executables in a folder bin/. I also have a folder inc/ which contains some headers (.h) and those headers possibly also have some associated TU (.cpp).
Now g++ can already generate a dependency graph of headers for an executable. It is then (with a standard Makefile and some supporting bash scripts) quite straightforward to mangle that graph into a list of translation units (namely those files whose name matches a depended-on header) which must be compiled and linked into the executable.
That is, I can simply create a new "executable file" .cpp file in bin/, include some headers therein and when I say make, the Makefile automagically figures out which (internal) dependencies it needs to link in when linking the executable.
Now that I have these "relatively straightforward" scripts and the corresponding Makefile, the incentive to move to another (nicer) build system which would require me to rebuild this infrastructure to fit into this other build system's view of the world is quite low – unless there is some way to do this directly?
Xmake as shown here (and also Meson linked in a sister comment) appear to still require manual selection of dependencies.
a) protecting the sensitive environment around the Lofoten islands
b) increasing the cost of oil slightly
c) leaving the oil around Lofoten for future generations if necessary
All three are quite positive effects of this decision, with a+c) being more limited to Norway and b) potentially having an effect world-wide. It will also make it easier to tax "dirty" oil imports (such as from sensitive natural environments) and all goods produced using such oil into the EU if no internal player is doing the same.