What classes of vulnerabilities are you referring to that are likely to show up in a microkernel-based design but not in a monolithic one? Do you think adding those classes of vulnerabilities to the picture will result in more, about the same, or fewer critical security issues between the systems overall, and why? Please be specific.
I prefer lazy-loading both packages and files, but still having
recently-worked-on files available for quick opening, since I
sometimes do restart Emacs :)
With the below form in my .emacs.d/init.el, I can restart Emacs and
the first time I do C-x b I get to pick from files I had opened in the
previous session:
(use-package ido
:init
(setq ido-use-virtual-buffers t) ; treat closed files as open buffers for C-x b
:config
(ido-mode 1)
(ido-everywhere 1)
(use-package recentf
:init
(setq recentf-auto-cleanup 7200 ; clean list on idle rather than startup
recentf-max-saved-items 2000)
:config
(recentf-mode 1)))
That is, ido-use-virtual-buffers will put closed buffers at the end of
the buffer list, while recentf makes that list of previously closed
buffers persistent across sessions.
Also, after opening vc-tracked files, I want subsequent find-file
calls to match on all non-ignored subdirectories of that repo, not
just the directory of the current file, so I use ffir to add tracked
subdirectories to ido's work directories:
(use-package find-file-in-repository
:ensure t
:config
(setq ffir-avoid-HOME-repository nil)
(defun ffir-repo-subdirectories ()
"Use ffir to put projects into ido-work-directories.
This makes useful files show up even if you haven't been to that
sub-folder yet."
;; TODO: compare emacs25 project-find-file
(interactive)
(let* ((repo-directory (expand-file-name
(ffir-locate-dominating-file
default-directory
(lambda (directory)
(ffir-directory-contains-which-file
ffir-repository-types directory)))))
(file-list (funcall (ffir-directory-contains-which-file
ffir-repository-types repo-directory)
repo-directory))
dir-list)
(mapc (lambda (p)
(add-to-list 'dir-list (file-name-directory (cdr p))))
file-list)
dir-list))
(defadvice ido-merge-work-directories (before advice-merge-repo-subdirs first nil activate)
(mapc (lambda (d) (add-to-list 'ido-work-directory-list d))
(ffir-repo-subdirectories))))
(ffir is a fairly small dependency for a vc-general
"list-non-ignored-files", though perhaps there's something built-in in
Emacs' vc.el I should be using instead)
Reminder: Unless you have an actual stake in the company, you do not
own anything you produce for the company. Keep that in mind the next
time code you worked on causes a 2am production server crash or is
responsible for increasing revenue x10. It is not your code that
caused the events but the owner's of the company.
I think that was a knee-jerk reaction to the word "ownership". That is not the sense used here. There is no contradiction in being given ownership of some task while having no ownership stake in the company; it's two quite different senses of the term.
I disagree - the distinction is still significant in that it's important not to let the responsibilities of ownership land on your plate when you're not getting any of the benefits.
You're not. It's two different meanings of the word. You aren't "responsible" for the running of the business because you've "taken ownership" of the autocomplete widget on the search page. You're getting paid for your ownership of the autocomplete widget, you're not getting paid for your ownership of the corporate direction.
If you're getting paid, you do need to be getting paid because of some responsibility you're discharging, after all.
You can tell it's two different "ownerships" by what happens if you quit. One you retain, the other is simply redistributed to some other developer. They're not the same thing.
I agree with both of you, and I wish there was a better word than "ownership". That term has implications that are inappropriate for a single feature. You don't own the autocomplete widget -- you're responsible for it but you don't own it, the company owns it.
You both own(1) the widget and do not own(2) the widget.
This is English. Multiple definitions for a word are common. Cases where only some definitions apply and not others are common. They happen in almost every sentence. Try to avoid letting that pollute your thought. (It is a challenge. No sarcasm.)
Ownership
Leaders are owners. They think long term and don’t sacrifice long-term value for short-term results. They act on behalf of the entire company, beyond just their own team. They never say “that’s not my job."
Unfortunately, we no longer live in a society where the employer-employee relationship is one of trust. The definition Amazon.com seems to be using is that owners do shit work and so should you, but maybe I'm misreading.
"Stewardship" might be the word we're looking for: it has some connotations of personally invested care, but it's also clear that it's done on behalf of someone else and there's no ownership.
Of course, it also has a history of association with servants of landed gentry, which might make people uncomfortable (for good reasons, to the extent the analogy holds up).
Salary is compensation for quantums of a person's life spent doing something for which he has (presumably) the skills to do. That's not a "benefit;" it's an exchange of value.
"Ownership" is a poor way to express the differences in meaning(s) indicated in this article.
Sort of. The sense that's being used here is a corporatism that means 'act with the level of commitment implied by owning something even though you have none of the rights benefits or responsibilities' - i.e. It is a form of doublethink required by the corporate hierarchy.
It is quite reasonable to ask 'why should I act as if I own think, when actually I do not?'
In my experience, people who are emotionally invested in their work tend to do much better work, and are worth proportionally more because of it. So whether this is correlation or causation, you are indirectly being paid to care as much as you do.
If you're not being paid enough to care that much, or you don't want to care that much, then it is what it is. From the hiring perspective, we should have negotiated a price that works for me and is enough for you to feel that you are fairly compensated for your ownership of the feature. It's a two-sided relationship where you have the ability to just back out of the deal if it isn't working for you.
True, but that generally isn't the stance that employers take when negotiating salaries - that they need to pay enough for people to feel ownership.
'You have the ability to back out of the deal if it isn't working for you' is a cop out for any failing that a corporation may have. It is true but also leads to no new understanding.
I disagree. I think its important to take 'ownership' of your work. Its the best way to obtain visibility in your organization and (for me at least) creates a sense of satisfaction and pride.
If I was just a cog in the machine of the corporate wheel churning through small tasks on a daily basis it would be hard to keep motivated. In fact a lack of ownership for work is what allows large companies to carry so much dead weight for so long. Employees stagnate and start coasting.
I do however take your point to heart and realize taking ownership does not mean I am up til 2am frequently trying to meet unrealistic deadlines.
There are two related but subtly different uses here. A word like 'he' is a default, which can lead to problematic implications. A word like 'guy', to some people, is a true neutral, implying gender no more than the word 'somebody'.
Even if we were talking about 'he', your link would be out of place. Calling out the use of a gendered default as bad is not in fact another point of view on whether it is the default.
Sometimes I will use it in a conversation when referring to a third party unknown to the person I am talking to and the subject's gender has no bearing (like in my first comment).
For example, "Oh, I know a guy that knows X," "I know a guy that is a fan of X" or in a less positive manner "That guy just cut me off [on the freeway]!" (since you rarely see who it might be and their gender doesn't matter)
I could say "dude" as well, but sometimes dude might be too informal. I could reword it with a number of other pronouns, but it depends on context and whom one is talking to.
"Hey, guys!" in reference to a mixed group is perfectly acceptable. "That guy" in reference to someone you do not know the gender of is also perfectly acceptable. Directly referring to a known female as "guy" is less so.
If I didn't know better I'd think he was trolling. He goes on to compare emacs to COBOL. I don't even like emacs (I use vim, of course), but it shows an unbelievable level of ignorance of the current state of emacs to act as though it's "ancient" and clearly inferior to the Visual Studio editor.
"Yes, there's been some development, but using Emacs on TOPS-10 or ITS is an awful lot like using it under Linux in 2010."
That's a huge stretch, and kinda like saying that using Linux is an awful lot like using SunOS 1.0. Sure, the basics of use are the same, and someone who used an ancient emacs version could pickup using a modern version reasonably easily, but syntax highlighting, auto-completion, X and GUI support, windowing, multi-file editing, etc. have been added over the years (and that's just stuff I know of, off the top of my head, and I don't even use emacs). The emacs distribution has grown by several orders of magnitude in size since those TOPS-10 and ITS implementations.
My point is that Emacs is every bit the editor that Visual Studio editor is, and contains pretty much all the same features, and a lot that Visual Studio will never have. And, more importantly, the most productive developers I've ever known used either emacs or vim...I can't think of a single great developer that uses Visual Studio (I'm sure they exist, but I've yet to meet one). It's just idiotic to claim that emacs is an ineffective tool when the evidence is so strong that it is extremely effective for millions of developers.
Well sure, it's definitely a fantastic development environment. I loved Emacs well enough at one point, although eventually my hand started to ache from constant M-x'ing and buffer switching and I gave it up. I'm just pointing out that Emacs is quite old, and that someone used to the 40-year-old version wouldn't really have much trouble using the most recent version, at least for the basics.
