-
Any way to get these without the FOIA watermark, would love to print these out?
-
-
Side topic, this story may explain an odd story from two weeks ago about how the Intel CEO sold all the shares he could. If he doesn’t have rock-solid documentation that the trade was planned before he learned this, that’s probably insider trading. (Hat tip to @goodger prompting me to look up the SEC rule in the chat.)
ETA: here’s the form 4 he filed. I’ve got to step out the door, but if anyone can figure out if this was reported to Intel before Nov 29 that would be interesting.
-
-
Good find. Looks like some press has it now, too. And a yc news commenter notes it’s not in their 10-Q, so that’s probably a couple counts in an indictment and a shareholder lawsuit.
-
-
Even if he knew, I think it matters whether this is a recurring event. If he always sells his shares at the end of the year, it would be insane to demand that he doesn’t do it.
Otherwise people could just start shorting as soon as they see an executive not selling stock, because they can infer now that there is some bad news incoming.
-
-
-
That article is pretty misleading. It’s true that the November sale was “pursuant to a pre-arranged stock sale plan with an automated sale schedule,” but that stock sale plan was pre-arranged only in October, months after Google had notified Intel of these vulnerabilities.
-
I thought these all had to be disclosed on Form 4s. Maybe there’s another reporting vehicle I’m unaware of, but “Krzanich’s plan seems to involve getting stock grants at the beginning of each year and then selling as much as he can in the fourth quarter, which he has done consistently for a few years.” is not an accurate description of the record in the linked form 4s. His sales happen in every quarter and this is the only time he’s sold down to Intel’s minimum (eyeballing rather than making a running total, but it seems clear).
-
-
-
-
-
A great talk on what’s really lurking between the opcodes your standard x86 chip
-
Just in case anyone wants an easy link to send to people for fixing this: https://9to5mac.com/2017/11/28/how-to-set-root-password/
-
atti1a
9 months ago
|
link
| on:
Java 9: Cleaning up your default methods using private interface methods
I’m not an expert on Java, but why are we putting method implementations into interfaces when we already have abstract class inheritance for (what feels like) this exact thing?
-
Interfaces allow multiple inheritance.
-
-
But that’s not the point of abstract classes. Abstract classes enforce that (1) you must inherit from only one of them and (2) you cannot instantiate them without inheriting them. If you remove either of these constraints you have a regular class, and there definitely are use cases where you want rules 1 and 2 enforced.
-
-
I disparaged Java 9 for this too, because it felt like they were further blurring the line between interfaces and abstract classes. After talking with some of my friends (pinging @dsh), it helped me outline some more differences. To expand and maybe give you more to work with:
abstract classes (to me) feel more class-y, even with these changes. You can’t have final methods in interfaces, nor can you have member variables. As mentioned, you also can’t have multiple inheritance with abstract classes - they are a strictly one-to-one relationship with child classes. Interfaces, on the other hand, are just collections of methods. All you’re doing with a default implementation is telling the compiler to use the given method body if it’s not been specified by the implementor.
That being said, I think the muddying does harm to people learning the language and the idea of OOP. It gives you two different ways to solve the same problem, and I can see that difference really messing with beginners/intermediates until they fully grasp the philosophy of OOP and when it really is appropriate to use an interface or abstract class.
-
-
-
No, the solution is default interface methods.
-
-
-
-
-
-
skade
1 year ago
|
link
| on:
Linus: “I no longer feel like I can trust "init" to do the sane thing.”
And yes, a large part of this may be that I no longer feel like I can trust “init” to do the sane thing. You all presumably know why.
No, I don’t. Please explain what you mean.
Such appeal to everyone “knowing what you mean” and the implication that everyone supports your standpoint are toxic. They are a good way of making a personal opinion look like a group opinion. Combined with a fuzzy notion of “sane”, this is basically just spreading bile.
And it works. If this mail were more complex or that sentence would be missing, it probably wouldn’t be here on lobsters. It’s certainly not posted for the review above it.
-
If you’re reading the kernel mailing list, it can be assumed that you have some familiarity with the subject matter, and if not, you’re not missing anything crucial to the discussion here. Torvalds has decided not to point and name the implied party, probably to avoid another heated flame war on the mailing list.
Some context to get you up to speed:
He is referring to what is currently the most popular init system on Linux,
systemd.systemdis a relatively recent development of Red Hat, and has been adopted by all major distributions. Prior tosystemdgaining popularity, the init system was a hodgepodge of shell scripts, which clearly had its share of problems.However,
systemdhas been adding more features to its resume. Besides just being an init system, it has also absorbed the hardware abstraction layerudev, it implements its own dbus daemon (a popular Linux message bus used to communicate between different services and programs), it has taken control of some power management features such as suspend on lid close for laptops, it implements login and virtual terminal handling, it contains a dhcp client and server, and it provides its own system logger using a binary format that can in practice only be used through the tools provided bysystemd.This attitude of trying to do everything from a single piece of software has proven to be somewhat controversial among Linux users, because the old UNIX mantra for software was “do one thing and do it well”. This is especially controversial for something as central as the init system, because it is always running and runs with elevated rights.
The lead developer of
systemdhas also responded to a few issues with some unpopular comments, and has in the past been in conflict with the Linux kernel developers by refusing to cooperate on certain issues caused by Linux andsystemdinteraction.systemdhas also, despite its widespread use, been hit by a number of fairly serious bugs, some of which had significant security impacts. The simplicity and potential impact of some of these bugs has left many people in doubt over the general quality ofsystemdand related projects.-
In particular Linus has had specific issues in the past - there was a problem a while back where kernel developers would boot with the “debug” flag and systemd would start spamming the console with messages and drown out the kernel information said developers needed. See https://lkml.org/lkml/2014/4/2/580 where someone proposed a patch that would remove “debug” from /process/cmdline so that the presence of that flag was completely unavailable to userspace (including systemd), thus literally preventing the problem from happening. Real icky situation.
-
-
There seems to be two main camps of users (3 if you include distro maintainers as a separate camp):
-
People who maintain a few systems, perhaps use Linux on the desktop.
-
People who maintain many systems.
Camp 1 people don’t mind when Systemd does something arbitrary, unexpected or indeterminate. Camp 2 people hate Systemd’s indeterminism.
Personally I hate magic. Systemd is magic. I can’t trust it to do what I want to do, only what it wants to do.
-
As a person who maintains many systems professionally, i have to interject here since I always see it stated as fact that professional operators dislike systemd. I like systemd a lot because it gives badly needed structure to Linux service management. Most colleagues who worked with systemd feel the same. (This doesn’t mean it’s perfect or bug-free)
-
-
There seems to be two main camps of users (3 if you include distro maintainers as a separate camp):
- People who maintain a few systems, perhaps use Linux on the desktop. Camp 1 people don’t mind when Systemd does something arbitrary, unexpected or indeterminate.
I’m a group 1 member but I absolutely hate when systemd doesn’t operate as I would expect a init daemon.
-
-
-
This attitude of trying to do everything from a single piece of software has proven to be somewhat controversial among Linux users, because the old UNIX mantra for software was “do one thing and do it well”.
I’ve found this mantra to be only applicable in certain situations, usually when it comes to applications that users directly interact with. Things like email clients, text editors, and IRC clients (web browsers could spawn an entire discussion on this all their own). I’m not an expert on init systems, and your previous paragraph on systemd clearly shows its feature creep. But when it comes to an init system, I’ve always seen that as a complex process where it’s necessary for it to do more than one thing. This can be especially true with modern systems where everything you’ve mentioned (HAL, dbus, power management, login, networking, etc) being (arguably) necessary for the system to run correctly and in a useful way.
So, I wonder, is it possible to have an init system that is:
- fast
- effective
- correct
that still abides by “doing one thing, and doing it well”?
-
The mantra predates text editors (well aside of ‘ed’), email and irc clients. Any user interfaces in the modern sense really. It meant using a bunch of small, single purpose programs (like
cat,troff,tail,ps…) which could be combined by user to the desired effect with standard system mechanisms like redirection, pipes and shell scripts.We can argue the practical merits of systemd forever but it’s fairly clear it goes against the tradition of UNIX systems development. It’s a huge, opaque, uncooperative beast that makes turtles cry. I hope Linus is close to the point where he’ll just come up with something more digestible.
-
The original idea behind that mantra was to make tools that were:
- simple (Note: I’m using the Rich Hickey definition here)
- composable. This composability requirement is why all the command line tools ingest and output strings.
As systemd takes over more of a Linux machine, they destroy their own simplicity, requiring someone to keep a massive amount of state in their head to modify the code or even work on units as an administrator. However, they also destroy the composiblity of the system’s tools. Things like binary logs and internal-to-systemd protocols can’t be parsed by standard command line tools, and thus users lose this ability to compose different parts of the system. This has been my biggest issue with systemd, that it violates not only “do one thing and do it well”, but also the composiblity that makes that possible.
A side note on GUI’s: The GUI design model is specifically the opposite of “do one thing and do it well”. GUI’s are not designed for composibility, they are designed to take the user from one end of a specific process to the other. They trade off the ability to compose with other programs, for a more robust control of the user experience.
-
The context of this discussion is around trying to bring sanity to rlimits for setuid processes…
In an attempt to provide sensible rlimit defaults for setuid execs, this inherits the namespace’s init rlimits:
$ ulimit -s 8192 $ ulimit -s unlimited $ /bin/sh -c ‘ulimit -s’ unlimited $ sudo /bin/sh -c ‘ulimit -s’ 8192
This is modified from Brad Spengler/PaX Team’s hard-coded setuid exec stack rlimit (8MB) in the last public patch of grsecurity/PaX based on my understanding of the code. Changes or omissions from the original code are mine and don’t reflect the original grsecurity/PaX code.
Certainly traditionally it has been trivially easy for a rogue daemon to bring a system to it’s knees…. since traditionally, out of the box, there are no rlimits imposed.
It is the init systems job to start daemons… it would be really nice if it imposes sane rlimits on anything it starts.
Systemd does that, and attempts to do it in sanish ways by imposing the limits on process groups. (ie. A rogue daemon cannot escape it’s constraints by spawning a legion).
I’m would be easily convinced that systemd’s approach is not the best and/or not correct.
However I’m certain that the linux ecosystem needs work in this area and systemd is at least undertaking that work.
-
You seem to be mixing up system daemons and setuid utilities. This patch has nothing do with the limits systemd imposes on the processes it starts, so whatever systemd does, or other systems did not do, in this area is irrelevant.
There’s no question that systemd is capable of setting rlimits for child processes. The question is whether the limits systemd sets for itself are a good default template for setuid processes run by users.
-
-
-
-
-
-
What qualifies as “insane”?
This might sound trollish, but I seriously don’t find “sane/insane” distinctions very useful (beyond their connotations). In my experience, these words get used when you can’t construct a better argument for why the other side is doing something wrong, so you call yours “sane” and the others “insane”.
-
-
That sounds like a nice definition, but “without reason or logic” is just as fuzzy, “counter productive, destructive, harmful” are also easily stated, but must be followed by hard facts to be held up.
Also, regarding the principle of least surprise: Matz (who popularised it) also famously said that it applies to his surprise.
Your definition just moves the playing field.
Also, I would argue that anyone implementing a piece of software so central to the Linux world is a “domain expert”. This is boundary play at its finest.
-
For a specific example: How would you classify the change to kill tmux servers after a user logged out? Lots of people found that surprising. And in the larger space of existing init systems, quite unprecedented. I think “insane” is lacking precision, but adequately captures many people’s sentiment.
-
-
Especially since it changes how every unix has behaved for almost 30-40 years regarding HUP.
Or a more recent one where it parses a username of “0haha” as being an invalid username and runs the unit as root. And now perfectly valid usernames starting with a number won’t work in systemd unit files as they get interpreted as being invalid because systemd can’t seemingly parse numbers in a config file sanely to distinguish a user name versus a user id.
This all might sound like splitting hairs, but breaking userspace (HUP behavior shouldn’t need a patch for your init in tools), and not parsing a username sanely are pretty basic things I would expect a first year undergrad to be able to do.
So yes, I agree insane is a good word to use for things. I could come up with hard facts, but systemd really feels like one step forward and two steps back for a lot of things. I don’t really feel like its a very good example of good engineering practices, aka binary logs that can be corrupted forcing you to do insane things to get a system online due to a short write to the filesystem is… also insane, we have decades of knowledge of how to do this that has been ignored.
If the corners aren’t rounded on this desk, why should I feel safe about the rest of the desk?
-
-
-
-
-
-
In my experience, these words get used when you can’t construct a better argument for why the other side is doing something wrong, so you call yours “sane” and the others “insane”
“In your experience”, huh? So you’re just extrapolating your own personal experiences to all of mankind, then? “Citation needed!”
You see, it’s easy to filibuster any conversation by calling for better argumentation, proof, evidence, studies to back claims up and so on.
You know perfectly well why someone might call systemd “insane”. What’s your actual contribution to the conversation, besides signalling to everyone what a rational and sophisticated person you are?
-
“In your experience”, huh? So you’re just extrapolating your own personal experiences to all of mankind, then? “Citation needed!”
No, I don’t. That’s why I wrote: In my experience.
You know perfectly well why someone might call systemd “insane”.
No, I don’t. I use systemd every day and I’m very fine with how it works and how it behaves.
It has, as all implementations of a thing, issues and flaws, but that’s all. I’d be happy to try an alternative, which would for sure improve in a lot of areas (and may be worse in others), but that’s a trade-off, nothing more.
What’s your actual contribution to the conversation, besides signalling to everyone what a rational and sophisticated person you are?
I’m highlighting a conversational pattern that is all too often used to create unity were there is none. I’m neither rational or sophisticated.
-
-
-
-
-
Does anybody know if the ebook will be available without the treebook?
-
https://www.alchemistowl.org/pocorgtfo/
Here is the collection of all the published pocorgtfo articles, plus these ones can be written to a boot sector.
-
Thank you so much!
-
-
-
Over Quota
This application is temporarily over its serving quota. Please try again later. … This means cant read :-(
-
-
maqio
RhodeCode Creator
1 year ago
|
link
| on:
New GitHub Terms of Service require removing many open source works from it
It’s best to host your code repository yourself, this is what our focus was since few years. Open source code management such as RhodeCode or Gitlab is always better when it comes to privacy and security.
-
While I definitely see the benefit of hosting your own repositories as a primary source, I would make the addendum that if you want to do this, you should have a mirror on GitHub. There’s a lot to be said for the centralized repository of open source code that GitHub has become, for contributors and users alike.
-
-
-
RhodeCode is very easy to deploy
Unless you are on a non-linux system :P
I recently tried to get RhodeCode up and running on OpenBSD - It doesn’t seem to be a trivial task. Is there something I am missing for other OS’s? or are they just not supported?
-
-
-
-
-
How I remember the untar command: tar Xtract Ze Files => tar xzf
-
An interesting thing to note is that the message on Libreboot’s website has now changed, stating:
It took the GNU project 4 months to finally honour Libreboot’s decisions, but on 5 January 2017, RMS formally acknowledged it - his reasoning is flawed. They should have immediately honoured Libreboot’s decision to leave GNU, but instead they arrogantly resisted it for months, and the only reason they gave up was because they realized that all of Libreboot’s core developers were OK with leaving GNU and still preferred to work with Leah Rowe.
Sounds like there was additional motivation behind RMS’s decision to let Libreboot go.
-
They should have immediately honoured Libreboot’s decision to leave GNU, but instead they arrogantly resisted it for months, and the only reason they gave up was because they realized that all of Libreboot’s core developers were OK with leaving GNU and still preferred to work with Leah Rowe.
The website is (controversially) maintained by Leah Rowe right? I find the 3rd person writing very odd.
-
Something I’ve noticed with a larger portion of free software advocates (definetly not all of them) is that they reject the idea that a piece of software belongs to its maintainer or author in any way. I guess that’s why RMS refused to let libreboot go and thought GNU could just maintain its own fork.
-
I definitely understand your point there, but if we follow that ideology, then the project would just as much not belong to GNU as it would not belong to the maintainer. This would mean neither party would have any say in what this software is and isn’t a part of, which would make disputes like this even more contested. I am not a GNU maintainer, nor do I know personally any of Libreboot’s maintainers, so I have no knowledge of what paperwork they signed. But from an ideological stand point, I don’t see this line of thought meshing with GNU’s actions.
-
I don’t think GNU doubted that libreboot could be forked from the GNU tree and that its maintainer can leave. I guess they find it acceptable to have two libreboot forks under the same name (or rather: “GNU libreboot” vs “libreboot”).
I feel like this debate (and /u/mjn’s comments) is indicative of that mindset. I don’t share it anyway.
-
-
-
-
https://xkcd.com/927/ The only thing I could think of after reading this
-
When it comes to storage, there will always be a billion different standards, however unfortunate it is. Everyone’s workload is different, everyone requires a lot of different features, which means there are lots and lots of niches to fill, and therefore lots of money to be made filling them.
-
-
Most of what I use Rust for is one-off tools or else coding assignments for school (which I unfortunately cannot share). I have a general rule of whenever I think C/C++ is the correct tool for what I’m about to do, I ask myself if I can do it in Rust. 90% of the time, the answer is yes, especially for command line tools that involve parsing input and then interfacing with a Unix kernel.
I do have a couple favorite examples of good uses of Rust as well:
OS Development - A few months ago, this OS tutorial was posted to Lobsters. It takes the basic tutorials from OSDev Wiki and replaces the C with Rust. Having done this tutorial in C first, I found it a great window on how much easier writing good code is in Rust. Plus, I’m biased in that I love OS development.
Servo - As anyone who keeps up on security can tell you, browser security is a gigantic pain, and memory errors in modern browsers are rampant. Servo gives the promise of reducing these vulnerabilities greatly using the borrow system in Rust. Servo is still a relatively new project, so there’s a lot of variables to account for, but I have high hopes that this will make browsing a more secure experience.
So ultimately Rust, like any other language, is a tool in your toolkit. My hopes are for it to one day evolve enough to where it can be used for large scale projects. Currently, if one wants to write a large scale native application, and they don’t trust themselves enough for pure C (something I think more developers should do), then they reach for Java or C++. I see Rust as having a bit higher of a learning curve, but many new groups seeing it’s benefits as not having the bloat of C++ or Java.
-
something I think more developers should do
Curious, why do you think most developers should try writing large scale “native” applications? (I’m assuming by “native” here you mean “compiles to machine code”.) In my experience it’s almost always better to keep the native bits as small as possible and put most of the non-performance-critical logic in another language that can be hacked on by a larger potential pool of contributors, modified without a complete compiler suite installed, and improved upon or extended independently of the release cycle of the core program.
-
-
-
[Comment removed by author]
-
-
I like the idea, but this
Be verifiable - you should be able to see your own vote.
is an anti-goal. Voting systems are set up to prevent you from seeing how you voted.
This may seem backwards at first, but consider this: under a system where you can see your own vote, you can voluntarily offer up proof of your vote to 3rd parties. While this isn’t an issue for those of us with good work/family/friends, it is a huge problem for people in abusive relationships, or children (who can vote, but are still living with their parents). Suddenly it becomes possible (even if made illegal!) for a spouse to demand to see their partners voting record; or for a parent to force their child to reveal how he/she voted.
And then there’s obviously the issue of “buying votes.” Right now, if you said to me “I’ll pay you $20 to vote for candidate X” I could say “yeah sure” and then vote for whoever I want. This would not be the case under a verifiable system, where you could say “prove that you voted for candidate X for your $20”. Obviously this would be highly illegal, and I’d argue that it wouldn’t happen very often, but it is an issue that doesn’t happen under the current system.
Anyway, I love the idea of crypo voting, but being verifiable is very bad. It brings our voting system from one where votes are anonymous, to one where others can verify how you voted if they drug you and beat you with a $5 wrench [https://xkcd.com/538/].
-
-
-
Yes, but vote-buying “the fact that you voted” is not a thing. Hell there’s nothing stopping you from turning in an empty ballot if somebody pays you to show up and vote “something”. Now is an abusive spouse going to beat their husband for not voting at all? I doubt it. coercion just-to-vote is not as damaging as coercion to vote a certain way.
-
-
-
So I 100% see the point you are making here, but I see this more as not fixing an already existing problem rather than creating a new one, ultimately coming from the fact that we have mail in ballots in all but 7 states.
For example, say I want to make a quick $20 bucks from the election. I apply for a mail in ballot, fill it out, and then sends it to the mayor’s re-election campaign office. This office checks that my ballot is filled out how I said it would be, and then sends it along to the voting officials, and pays me $20. Alternatively, if I live with a controlling parent/partner/other, they can verify my ballot is the way they want it before sending it.
The solution to this is similar to the solution for the mail in problem, which is vote invalidation. The idea is that I can vote as many times as I want, and each time I will get a different identifier. However, only the last vote I make will actually be counted. This allows me to vote however an outside force compels me too, so I have verification, and then vote again with how I truly feel. As an added bonus, we get the solution to people who fat finger the button or otherwise see that their vote is different than they wanted after they go home and check the block chain.
The downside to this solution is that it would be easier to DDOS the system by sending massive amounts of votes, because you would need to add every vote to the block chain. I’m not sure how this problem would be solved, but it doesn’t sound intractable.
-
-
One problem here is that it wouldn’t be possible to also verify that your vote (the last one you submitted) was included in the results (as your sibling commenter suggested) because then outside actors would be able to verify that you hadn’t overridden the vote you showed to them. It’s a tricky problem… :-)
-
-
-
After a while working at the school, I have finally been given an office, a desk and a computer, so I’ve been provisioning my machine in celebration. Otherwise, continuing to help teach the freshman level security class (they’re doing very well) and my staple, System’s Programming. On the side, getting back into Haskell in preparation for trying to land an internship for the summer.
-
Any descriptions of the attack beyond a “very sophisticated password attack” yet?
-
It seems like Riot may have acted prematurely in doing this. This kind of tactic really will only work once, after which everyone will get multiple accounts and make sure they stay safe on their “work-LoL”. Do they have anything to prevent this behavior?
-
A) Human beings are so bad at operational security.
B) A 3-month-old account of an obviously talented (by game stats) player is clearly not their first one.
-
-
The HipChat MacOS client is only using 40MB of RAM. I don’t want Slack’s resource usage. 👎
Might I suggest https://github.com/wee-slack/wee-slack. At $WORK, we have a bunch of folks using it for Slack integration and it’s been a pretty good UX.