<kentonv>
yes the breakages seem to coincide with test runs
<kentonv>
so syslog stopped syslogging?
jeffmendoza has joined #sandstorm
<kentonv>
that seems rather bad?
<paulproteus>
Yeah, there's a big blob of ext4 NULLs and then the bootup starts.
<paulproteus>
The thing has no swap.
<paulproteus>
You could imagine an OOM killer gone awry I guess, but I really don't remember the OOM killer's algorithm.
<kentonv>
well, in theory it should start by killing the thing that's taking all the memory
<paulproteus>
I'm tempted to stick to my "killall qemu" strategy and see if things get better, and if not, try adding swap in 3 weeks if it fails similarly.
<paulproteus>
Yeah, I agree that in theory that's what it should do.
<paulproteus>
And SSH and init are unlikely to be taking all the memory.
<kentonv>
the algorithm is fairly complicated and ad hoc but I think it would at least kill non-root processes first...
<paulproteus>
Agreed; I remember it is supposed to have that bias.
<paulproteus>
Also SSH didn't accept(), nor did I get Connection refused, so that feels like the kernel was sad rather than userspace was sad.
<paulproteus>
Which is just to further say I'm confused.
<paulproteus>
In other news, I have vagrant-spk questions. How should we do versions?
<paulproteus>
Should I do vagrant-spk releases that have the same version numbers as Sandstorm, and try to release them on the same day?
<paulproteus>
That's my current plan. Alternatively we could have periodic releases named for the date of the release.
<paulproteus>
I figure we need releases because I don't know that it makes sense to update the Windows installer EXE with every git commit.
<paulproteus>
But I could also totally do that.
<paulproteus>
It's a pretty automated process.
<kentonv>
I don't have a strong opinion off the top of my head.
<paulproteus>
In the absence of input, my plan is to try to do vagrant-spk releases on the same day there are Sandstorm releases, and use the same version number, and that way Sandstorm 0.100 and vagrant-spk 0.100 are sensible to use with each other.
<paulproteus>
We could even pin vagrant-spk 0.100 to bundle Sandstorm 0.100 if we wanted to get slightly crazy.
<kentonv>
that seems reasonable
<paulproteus>
I don't know that I actually want that, though, but I could be convinced.
<kentonv>
I mean, coordinating releases seems reasonable
<paulproteus>
It does mean that there's an excuse for a new vagrant-spk version whenever there's a new Sandstorm version, which avoids a problem I was wondering about.
<paulproteus>
Specifically if sandstorm is 0.101 and vagrant-spk has no new commits so the latest is 0.100 will this confuse people?
<paulproteus>
If we always do a vagrant-spk bump with a sandstorm bump then nope it won't confuse people 'cause it won't happen.
<paulproteus>
vagrant-spk doesn't do any kind of notification oldness or auto-update checking or (on Windows) auto-update installing or (on Mac & Linux) auto git-pulling itself, at the moment.
<paulproteus>
We could fake it by having it check if it's >3 weeks old and then say "You probably want to update. Go read this page in the docs."
isd has joined #sandstorm
mort___ has joined #sandstorm
<ocdtrekkie>
Well, now I have the choice to suffer the agony of Android 5.x or be permanently vulnerable to a hilariously bad security vulnerability.
<ocdtrekkie>
... I want Windows 10 for phones to hurry up and release.
<ocdtrekkie>
Someone needs to make Android support proper security lifecycles. Vista still gets security updates.
<XgF>
ocdtrekkie: so does 4.4 (just not for phones which have a 5.x release)
<XgF>
and I'm not sure what the "agony" of 5.x is...
<juri_>
not being cyanogenmod. ;)
larjona has joined #sandstorm
<kentonv>
juri_: Ironically, I just learned today that CM won't OTA-update to a new major release; I need to wipe my phone. I'm probably going to go back to stock Android as a result.
jinnko has joined #sandstorm
<kentonv>
ocdtrekkie: To be fair, Nexus devices have prompt updates and long lifecycles (as phones go, at least).
<larjona>
Hi! paulproteus I'm stuck with framadate packaging, in the same place as we left it; couldn't put more time on it since then. I'll go on tonight (4h later or so), but not sure what to do, so, probably, will send mail to the list, and try to package other php app to see what happens
<juri_>
kentonv: patches welcome. ;)
<juri_>
I need to wrangle replicant onto my devices.
<paulproteus>
larjona: Cool -- I don't really have a sense of what you're stuck on, so if you can give me your .sandstorm/ directory and any code changes then I can see if I can help!
<ocdtrekkie>
kentonv I don't want 5.1. But there's no security updates I can install on my phone for 4.4.
<ocdtrekkie>
This is a design flaw.
<ocdtrekkie>
XgF: Lollipop is a downgrade in almost every respect from 4.4.
* XgF
vigorously disagrees
<ocdtrekkie>
It should be a consumer rights issue to push it as an update.
<ocdtrekkie>
And I'm probably going to tell Verizon off for continually pestering me about it.
<XgF>
"In every respect"? It's faster. It uses less RAM. It looks better (YMMV)
<ocdtrekkie>
It's slower...
<ocdtrekkie>
And it looks worse and is more exasperating to navigate. (YMMV)
<ocdtrekkie>
People have already reported major slowdowns in 5.x "upgrades".
<XgF>
And people have also reported major speedups
<XgF>
ocdtrekkie: But how many versions is a vendor supposed to support and for how long?
<XgF>
My old phone is on it's 5th major version. Should all 5 versions be receiving security uprgades?
<ocdtrekkie>
XgF: Three years minimum for a cell phone OS.
<XgF>
For all 5 versions? That's unreasonable
<ocdtrekkie>
Doesn't matter how many versions. Google's instability isn't customers' problem.
<XgF>
And I don't see how Windows Phone 10 will be better - Microsoft won't let you turn off upgrades on that
<ocdtrekkie>
You need to support for one year on the market plus two years on contract.
<ocdtrekkie>
Failing to do that is proving a platform unviable for security purposes.
<ocdtrekkie>
Nobody should be using Android at this point.
<XgF>
ocdtrekkie: So you're saying that my old phone should still be getting security updates for the 3 people who want to run Android 4.2 forever?
<ocdtrekkie>
Their 'security lead', if he deserves that title, only supports security fixes for 18 months, which is not even the length of a standard phone contract.
<ocdtrekkie>
For three years, XgF, yes.
<XgF>
I'd say that's ridiculous
<ocdtrekkie>
I'd say otherwise is ridiculous.
<XgF>
I'm not sure how sticking on 4.2 would help you anyway - all the apps will be the same versions...
<ocdtrekkie>
And three years is a conservative requirement. Bare minimum.
<ocdtrekkie>
Anything less, Google should be financially liable to any flaws they leave knowingly unpatched.
<XgF>
ocdtrekkie: Microsoft won't be providing 3 years of support for Windows 10 either, BTW
<ocdtrekkie>
They sell a platform knowing the average contract length. They knowingly choose to provide a system that won't be supported for its natural life in consumers' hands
<XgF>
ocdtrekkie: You *can't even opt out of updates* on Windows 10 Home or Windows Mobile 10
<ocdtrekkie>
Last I checked, XgF, they hadn't announced Win10s.
<ocdtrekkie>
For mobile.
<ocdtrekkie>
And that refers mostly to security fixes, something Google refuses to provide.
<ocdtrekkie>
Microsoft won't mandate something like a Material redesign on customers.
<ocdtrekkie>
Security fixes should be mandatory. They also shouldn't change the platform in any significant manner.
<XgF>
"Microsoft won't mandate something like a Material redesign on customers." [citation needed]
<ocdtrekkie>
Forcing 5.x on people to get basic product security is wrong.
<XgF>
(note: what they force on business customers is another matter)
<ocdtrekkie>
Also, can you honestly say what Google does with Android meets even basic enterprise guidelines?
mort___ has quit [Quit: Leaving.]
<ocdtrekkie>
Android for Work? A nonstarter with an 18 month support cycle.
<XgF>
ocdtrekkie: All Google devices have a 3 year minimum support cycle
<XgF>
(there have been reports to that effect regarding Nexus devices from M onwards)
<ocdtrekkie>
So, Android for Work only if you buy Nexus? And then with no guarantee your internal apps will work for three years.
<XgF>
ocdtrekkie: For other devices you'd need to take up the support terms with your supplier...
<ocdtrekkie>
IE11 will get security updates indefinitely for a reason.
<ocdtrekkie>
XgF: Google is responsible for the updates.
<ocdtrekkie>
They refused to release a patch for 4.3. To a bug in their own code.
<XgF>
ocdtrekkie: Yes, because the fix is in 4.4.
<ocdtrekkie>
That's not a security patch. That's a forced system upgrade.
<ocdtrekkie>
Aka: Not an answer.
<XgF>
Do Microsoft release updates for Windows 7 without any service packs any more? (answer: no)
<ocdtrekkie>
Particularly given the cost to OEMs of deploying that.
<ocdtrekkie>
Service packs do not significantly change the OS.
<XgF>
Did you ever install XP SP2?
<ocdtrekkie>
Yes.
<ocdtrekkie>
Also, nice decade old example?
<XgF>
A service pack which majorly changed the OS
<mcpherrin>
Does windows 8.0 get updates? or do you need to 8.1?
<XgF>
mcpherrin: Windows 8.0 support ends 2 years after 8.1's release date
<XgF>
(this, to me, isn't much different from the EOL of 4.3 updates 18 months after 4.4)
<ocdtrekkie>
mcpherrin: That's a pretty valid concern.
<ocdtrekkie>
Thankfully the affected userbase is much smaller.
<XgF>
That's a great defense...
<ocdtrekkie>
Compared to 60% of Android users being outside of Google's security support?
<ocdtrekkie>
I'm not saying I like it, XgF. Nobody said Microsoft was perfect.
<XgF>
ocdtrekkie: Does it matter if those users wouldn't get the security updates anyway?
<ocdtrekkie>
XgF: who came up with that awful distribution methodology?
<ocdtrekkie>
Google needs to separate platform updates, which require heavy OEM work to deploy.
<ocdtrekkie>
And security updates, which should be directly released.
<XgF>
ocdtrekkie: Funnily enough, increasing amounts of the security critical platform components are being updated through Play
<mcpherrin>
Well, Google Play Services is that platform for a lot of things
<XgF>
e.g. since 4.4 Play Services contains OpenSSL; since 5.0 it contains WebView
<ocdtrekkie>
XgF: So we just make it a closed source platform then.
<XgF>
ocdtrekkie: Erm, this doesn't remove OpenSSL or the WebView from the base platform...
<XgF>
It just means that the platform contains hooks so Play Services (or Amazon Services, or Cyanogen Services, or whatever) can override them
<XgF>
(much like how location services has always implemented plugin delegation)
<larjona>
paulproteus: I've just sent mail to the list with everything what I have now. I'll come back after 3-4 hours,now time to some debian work :)
<paulproteus>
(-:
<paulproteus>
Thanks so much larjona !
jadewang has quit [Remote host closed the connection]
<paulproteus>
I can also be more clear about what "reasonable" means!
<dwrensha>
ah, the scrollbar overlaps the text
<paulproteus>
Yeah, exactly, ++ re: easy to not copy that part.
<dwrensha>
that's suboptimal
<paulproteus>
I guess yeah, I just set the height to 60px and I can live with it now.
<paulproteus>
(And I didn't need all 60 of those pixels.)
<paulproteus>
I do still kind of wish you were telling me to copy-paste a basic auth git repo URL since that is a bajillion times simpler.
<paulproteus>
But it's also a fairly unreasonable thing to do.
jadewang has quit [Ping timeout: 244 seconds]
<paulproteus>
One day we'll have an SSH driver hopefully, and we can use a random URL component plus SSH key auth, in which case copy-pasting a cloneable URL would work?
<paulproteus>
I didn't see the blog post, but yeah, I'm aware of that possibility of a config problem.
<paulproteus>
Mumble-grumble "0.16% of the Internet should be about clients & IP address ranges not URL ranges, web != Interent"</curmudgeon>
<paulproteus>
But yeah, I can agree that copy-pasting a basic auth URL is unreasonable. Is my SSH proposal plausible for the future? If so I'm extra willing to live with whatever for now.
<paulproteus>
But anyway I am +1 on this! So long as the scrollbar no longer overlaps the text.
<paulproteus>
Semi-sad that it's sort of absurdly long, and maybe it deserves an explanation of why we're so unusual.
<dwrensha>
paulproteus: an explanation would only make it longer!
<paulproteus>
I think if there were a "Click here for explanation" that would go a long way for people who are less in love with Sandstorm than I am.
<dwrensha>
paulproteus: I don't really have a good picture of what would be feasible with SSH access to Sandstorm. But I think I agree with you about what would be desirable, from a usability standpoint
<paulproteus>
And have it be collapsed by default.
<paulproteus>
Then at least people won't ask me why it works the way it does.
<paulproteus>
But I'm already +1 on this change if you make the scrollbar not overlap the text on my laptop (I realize this is semi-hard due to differing fonts between operating systems) and extra +1 if there's an "Explain" thing.
<paulproteus>
Sorry if I sound a little grouchy this morning.
<dwrensha>
paulproteus: thanks for the feedback
<paulproteus>
(-:
<paulproteus>
You are welcome and I really do appreciate all the work you've put it into, and I accept that the perfect can be the enemy of the good, and that there are time trade-offs in everything.
<dwrensha>
oh, grrr... those instructions actually don't quite work always, I suppose because `git credential approve` needs to know which helper to use.
jadewang has joined #sandstorm
<paulproteus>
Also dwrensha I sort of hate that blog post because (a) I think Apache on Debian had some bundled config to avoid this, and everyone now like self-installs nginx like a cool devops hipster so they don't get the benefits of Debian, (b) I kind of want to tell those people, open source is good source! (c) Internet vs. web.
<paulproteus>
Which is not to say the post is wrong in any actual way.
<paulproteus>
Fascinating re: git credential
<paulproteus>
Let me try this.
<paulproteus>
FWIW it still prompted me for a password.
<paulproteus>
I think I prefer without the \ honestly
<dwrensha>
really?
<dwrensha>
I like how the git commands line up now
<paulproteus>
|\ looks so weird!
<paulproteus>
And the git commands lining up is weird if there's really a command before the git command.
<dwrensha>
is there a more sh-idiomatic way to write that?
<paulproteus>
You could do (echo whatever | {{newline}} git {{args}})
<paulproteus>
At this point I'm sort of translating Python idioms to sh and it's not clear if that's just because I'm Asheeshy or because my opinions are universal.
<dwrensha>
parens!
<dwrensha>
I had no idea!
<paulproteus>
Seesm to work on this bash.
<paulproteus>
Works with dash too
<paulproteus>
That seems pretty solid.
<dwrensha>
heh, so we need to do `git -c <config> credential approve` and then `git clone -c <config>`, and the placement of the -c flag is crucial in both places!
<dwrensha>
for `git clone`, the flag needs to come after `clone` so that the config gets written to "new_repo/.git/config"
mort___ has joined #sandstorm
mort___ has quit [Ping timeout: 264 seconds]
<paulproteus>
kentonv: Unless instructed otherwise, I will use GitHub's "releases" system to store vagrant-spk Windows EXEs.
<geofft>
you don't need to escape the newline after a pipe in POSIX sh, IIRC. certainly works that way in bash
<paulproteus>
Which is to say, if you want me to use dl.sandstorm.io to host the EXE I can do that instead; just let me know how.
<geofft>
in fact, the parens do nothing there -- try (echo foo <NL> echo bar) or { echo foo <NL> echo bar }
* geofft
may have been reading the POSIX sh spec a bit too much recently
<paulproteus>
I'm hopeful geofft that your shell will be called /bin/nutsh
<paulproteus>
UNIX in a nutshell
<paulproteus>
I have long wanted to make /bin/nutsh (and similarly /bin/asheesh).
<paulproteus>
If you beat me to it I will be grateful.
<geofft>
nutshell is a pretty great name.
<dwrensha>
geofft: that would explain why "|\" looks funny.
NOTevil has quit [Quit: Leaving]
<paulproteus>
I think a | at the end of a line, without a () around it, is likely to get lost in copy-paste -- that is, in (a | b) people might run b without typing in a
<paulproteus>
Through careless copy-paste.
<dwrensha>
in any case, I decided not to break up the lines in my offer template
<paulproteus>
+1
<ocdtrekkie>
Someone says CM nightlies have a fix for the Android vulnerability.
<ocdtrekkie>
If that's useful to anyone.
<ocdtrekkie>
FYI XgF, others on HN are specifically saying what I told you here. That its ridiculous that Google doesn't provided security support for a minimum of three years.
<ocdtrekkie>
And that security updates should br
<ocdtrekkie>
Be pushed separately from feature updates.
isd has quit [Quit: Leaving.]
<geofft>
do I get relative ordering guarantees in capnp-rpc?
<dwrensha>
geofft: which implementation?
<geofft>
I guess I should wait for the first RPC's promise to resolve before dispatching?
<geofft>
rust, at the moment
<dwrensha>
In the full protocol there's a notion of "E-order".
<dwrensha>
the Rust implementation currently doesn't make any attempt to enforce it
<dwrensha>
It's possible that you'll hit an "unimplemented" panic before you can get messages in the wrong order in capnp-rpc-rust. I'm not sure.
<dwrensha>
That is, the implementation is incomplete enough that it might not matter.
<maurer>
dwrensha: my understanding is that the e-order enforcement can only become an issue if you support recieving as a return value a reference to a capability on your own machine
<maurer>
e.g. the bad case was something along the lines of
<maurer>
f.foo() (where f is the return of a previous rpc)
<maurer>
f resolves, and turns out to point to a local object
<maurer>
f.bar()
<maurer>
bar beats foo to f because foo has to reflect off the host that returned f
<maurer>
I don't know whether you support the relevant messages, but that's where you start needing the embargo/unembargo stuff
<dwrensha>
hm. It would be a fun exercise to construct such an example and see where capnp-rpc-rust goes wrong
<dwrensha>
... and submit it as a github issue :)
<dwrensha>
i suppose the c++ unit tests would be a good place to look for examples
<XgF>
ocdtrekkie: Sure, and I don't think 18 months of security support is that unreasonable
<XgF>
ocdtrekkie: It's 18 months more more than you get for iOS. It's 6 months short of what you get for OS X. Meh.
<XgF>
What *is* unreasonable is vendors not pushing updates within reasonable timeframes
<XgF>
(note: If you're a device vendor and you can't afford to fund people to provide 36 months of updates for all of your phones, perhaps you should join the Android One program where Google do it for you)