Presumably it's grounds for the registrar to send them a notice to update their information. But also having a domain name shouldn't require an impressum. The current domain registration system is complete BS.
If CP/M had used environment variables for configuration, presumably there would have been an established standard for TMP vs. TEMP that DOS would have adopted. The real catch, however, is that CP/M didn’t have directories. Nor did DOS 1.0.
"Rewind to 1973. The operating system common on microcomputers was CP/M. The CP/M operating system had no environment variables. That sounds like a strange place to start a discussion of environment variables, but it’s actually important."
"Over time, programs were written with MS-DOS as their primary target, and they started to realize that they could use environment variables as a way to store configuration data. In the ensuing chaos of the marketplace, two environment variables emerged as the front-runners for specifying where temporary files should go: TEMP and TMP."
And before that there are a few paragraphs describing the migration of applications from i8080/Z80 based CP/M towards x86 based DOS via mechanical translation.
Sounds like the short answer is "because there was no standard for the variable set by MS-DOS from the get go".
The background is that the issue hadn't existed in CP/M because there hadn't been environment variables. Perhaps if the issue had already been seen in CP/M, the developers of MS-DOS might have defined a standard variable to avoid it. Maybe. Other than that it doesn't seem to have much to do with CP/M specifically.
I was curious seeing this thread, and I just looked and don't get it either. AFAICT the CP/M references could have been entirely omitted and nothing in the narrative about TMP and TEMP would change.
Except that DOS was made to have its first programs ported from CP/M, so it’s relevant to explain that there were no environment variables to inherit from CP/M and no developer habits or program standards to inherit from CP/M programs.
Multics had envars in the 1960s and Unix in the 1970s, why were they ‘added’ to DOS when it was so close to an older OS, why didn’t it inherit them from CP/M? Did it get TMP from CP/M and introduce TEMP because computers were bigger but then?
This is an idealism vs realism fight. You're both right in that you're both fighting for the end user to have ultimate control of their device.
However, there's a major caveat here. Google's play protect prevents me from using some apps on my phone running graphene. My banking app is one of them. Yes I know there's technical workarounds. Yes I know they have a website (for now). But the point is, this is the direction stuff is moving. Fully signed devices from power-on through the entire stack and a flag that warns software if that breaks. Yes, it's a win for security. But I have zero control. Google has all the keys to all the doors and graphene can't do anything about it. Nor can I. And Google has very little incentive to change this.
I fear this is the direction things are moving to. Phones will be tied to our identity. Web will be depreciated as a security risk. Only one of the two options you two are fighting over fixes this: power must be taken from these mega corporations.
> Google's play protect prevents me from using some apps on my phone running graphene. My banking app is one of them.
Well, your bank is the one choosing to prevent your from running it on GrapheneOS. That's my whole point again! We need to regulate that: it should be forbidden to ban alternative OSes!
Now complaining about the fact that side-loading will require a ONE TIME, "annoying" procedure is not helping this AT ALL. It's just "oh no, I could do it with one click, and now I have to do it in 9 clicks, that's terrible, we need to bring it back to 2 clicks because anyway we won't win if we hope to bring it back to 1 click".
I'm exaggerating of course, it is a big problem for e.g. F-Droid (and maybe others?). But my point is that it's just cosmetic, it's not helping the cause. It's not moving us one inch closer to a better world. On the contrary: it's monopolising the attention of policymakers. They already don't understand much, and we flood them with complaints they don't understand (because really, 99.99% of the Android users don't give a shit about side loading, why would the policymakers care?).
The solution is simple: make it mandatory to allow alternative OSes (which is pretty much as simple as making it mandatory to unlock/relock the bootloader, and maybe remove a few other barriers that exist just for locking us in) and making it illegal to ban alternative OSes with Play Integrity (which is what banks are doing). That's all. No need to fight every decision Google makes and still lose every single time.
We need to get our act together and get the policymakers to do the right thing. But to be fair to the policymakers, technical people on the internet are asking for everything and its contrary.
I'd be happy with either approach, frankly. I just think yours is slightly less realistic.
> Well, your bank is the one choosing to prevent your from running it on GrapheneOS. That's my whole point again! We need to regulate that: it should be forbidden to ban alternative OSes!
The bank isn't banning graphene os. They're banning anything Google labels as untrusted. I think that's an important distinction. This is Google's doing. I don't have the ability to declare "this is my device and I trust it and everything on it" to the banks. And I can see Google's point in that it would be extremely difficult to do this in a way that couldn't be exploited maliciously. Are there ways for the .001 percent of people out there who understand this? Absolutely. But only if our overlords let us and even then we're back to the point that this is only for the people in the know.
Which is why I personally don't think enforcing alt OSes will help. We have it now; most people don't know and wouldn't care if they did. Play protect is the same. The amount of people this would impact is beyond minimal. However the problem isn't minimal; this is already a huge problem and it's getting bigger quickly. Giving people the keys won't fix it fast enough, or for enough people.
Tech already controls our life and that fact is only getting more worrisome. It's past time for the governments to treat this the same as electricity. Everything standardized, everything regulated, and I can plug whatever the hell I want into it. I don't want to just break free for myself. In order to really make change, my grandma needs to think of her phone like a power outlet.
> The bank isn't banning graphene os. They're banning anything Google labels as untrusted.
I don't agree here :-). AOSP provides an attestation mechanism that totally works with GrapheneOS [1]. Google provides Play Integrity on top of that, as an easy way to check that the phone is signed by Google. It doesn't say "it's unsafe if it is not signed by us", it just says "here is a way to verify that it is signed by us".
The bank chooses to check that it is signed by Google and to refuse everything that is not. The bank chooses that.
First, they don't need to check at all. Many banks don't, it seems like it's a new thing. I don't believe that there is any security concern there: it probably has to do with policy, or security theatre. It isn't serious security, because serious security would not ban GrapheneOS. I doubt it is to help Google, I think it's just incompetence (and a cheap way to do security theatre).
Most apps run on GrapheneOS, most apps don't use Play Integrity. Those who do choose to do it. And there are banks that choose to support the GrapheneOS attestation, though it's the exception.
I feel like this is semantics. I don't know all what they say, but I'd eat my breakfast cold if the word "safety" didn't come up in the PowerPoint deck. We may have to agree to disagree on this.
My point was that this is the direction the world is moving to. Maybe it's not total coverage yet, but every year more and more of our stuff only operates with verified trust through the entire process. Everything from video games to movies to programs. We're already sitting here complaining about Google enforcing developer verification, how long until Google turns on play integrity by default? And then how long until it's the only option? It'll come if something doesn't change.
And I still agree with the post way up above that these devices are too important now. I don't care about Google's interests here.
> My point was that this is the direction the world is moving to.
And I agree with that, but it feels to me like it reinforces my initial point: fighting the Google flavour of Android is a lost cause.
> We're already sitting here complaining about Google enforcing developer verification
Which isn't a problem on alternative Android OSes like GrapheneOS.
> how long until Google turns on play integrity by default
Agreed. The solution is to be able to use an alternative Android OS like GrapheneOS :-).
> It'll come if something doesn't change.
And what needs to change is that regulations need to make it illegal to actively choose to ban alternative Android OSes.
The thing with regulations is that you need to find something applicable. When people complain about centralised system and lobby for regulations that will help their federated system, without even debating about whether or not the federated system is "better", the fact is that it is not applicable. It is not reasonable to say "so now, if you write a messenger app, it has to use the Matrix protocol because Matrix convinced us of it". If I want to write a different protocol, I should be able to do it, right?
But what I am suggesting here is both reasonable and applicable: currently those banks have to add code to their app in order to ban alternative OSes. If a regulation makes it illegal, they just have to remove it, and banks who don't have it yet just don't add it. It's easy to verify: if my banking app doesn't boot on GrapheneOS, I can complain to the regulator, and the regulator can trivially verify it.
Same thing for allowing to unlock/relock the bootloader: super easy to verify, a regulation would work great.
Now back to the article: what are we asking? That the process of installing an unverified app manually is not made "so hard", with "hard" being some variant of "it's terrible if I have to wait 24h one time in order to enable this", for something that approximately nobody does. Look at all the effort that has been put against this change... and again they will lose. And if they managed (very unlikely) to get regulation for that, they would be screwed next week by the next change.
That's why I say it's the wrong fight: not only it's a lost cause, but it is strictly less useful than the simpler solution of defending alternative Android OSes with simple regulations.
The plan to rely on the presence of alternative OSes is only good so long as those OSes exist. They do today, but it is more of an exception rather than a rule. In a hypothetical scenario, where a signifcant portion of users switch to one of these alternative OSes, there will be an incentive to monetize.
So I'd agree there should be rules what OS should and shouldn't do. And yes, it shouldn't be a fight with an enterprise entity, which has little incentive to restrict itself. It should be a lawmaker level discussion, unfortunately they are pursuing other agendas over there.
> In a hypothetical scenario, where a signifcant portion of users switch to one of these alternative OSes, there will be an incentive to monetize.
Which is why it's better to choose an alternative that is open source, so that when they become evil, you can switch again. It's always been like that: we're fleeing from successful companies becoming evil. What has changed is that those companies have found a way to make it illegal for us to flee, and I suggest we fight against that.
> If you hover over a line of code in your application, coding assistance services will display code strings of supported function calls available through the coding assistance service that are also present in your current code file. Coding assistive services will retrieve snippets from publicly available open source code showing how others are using those same functions. 3. THIRD PARTY COMPONENTS. The software may include third party components with separate legal notices or governed by other agreements, as may be described in the notices file(s) accompanying the software.
I've read that paragraph multiple times (both in the original and in your post) and I don't see anything that says who owns the resulting text. Just where it comes from. Am I missing something obvious?
>will retrieve snippets from publicly available open source code
Pretty sure it depends on the license the open source project uses. I dont think it's too troublesome if the autocomplete was truly only taken from open source projects, but it wouldn't surprise me if most closed source projects are also weighted into these models...
Being a Graphene user is fine and all, but if this continues it will have a chilling effect on OSS Android development. And that will still effect you.
Why isn't it practical? In my life, I've encountered many SWEs that have changed careers. I've met them in national parks working as rangers. In real estate, grocery store butchers, and yak ranchers. Yet I've never once encountered a SWE that was once doing something non-technical and decided to switch.
Purely anecdotal, I know. But still, I prefer to think that all those people discovered this practical advice and are far happier for it. I've never met one that regretted their decision.
Oh, I would consider becoming a park ranger as well, but as a european, I also did not had to go deep in dept, to become a SWE.
And a professor should take that into account and give practical advice. In the real world, solving haskell challenes (of which the prof is fan of) is unfortunately not that useful. People have real needs for working software to solve their real pain points. Not to worship code quality.
Some projects need obviously better code quality (airplanes, medical equipment..) - but not all of them. And if you want to have sacred code when coding a crude throw away app .. you won't get enough money for that. And positions for academics are limited.
I thought about it, but it turns out the clover that people use for lawns isn't native, and I figured that if I'm doing the lawncare, I'm going to go as native as possible. I don't think our natives here in the US - trifolium reflexum and trifolium carolinianum - work very well as a "lawn" like that. I do have the carolinianum seeds that I want to grow in a container. Both are rare, so I want to help keep them in existence.
I'm looking into native sedges right now since they provide a lot of ecological benefit and are better-suited to growing in the soil conditions of my yard.
Around here, it isn't possible to do native lawn. The grasses are too tall and the low groundcovers can't be walked on. I'm trying to plant wildflower meadow but it will be a couple of feet high.
My idea is that there are two types of lawns. There are the lawn you use, and it is fine to be grass. But there is a lot of lawn that is landscaping and that can be native plants.
Oh, do you perhaps mean Theodore Payne Foundation at https://theodorepayne.org/ ? I was just searching Thomas Payne Foundation and that was what came up
I had a yard of mostly white clover years ago. The neat thing is that animals love it, I'd get 3 or 4 rabbits in my yard each morning - they seem to eat the white flower off the top.
The other nice thing is they don't need cutting nearly as often. I only had to cut the lawn because the stray random grasses and weeds that grew among the clovers.
reply