Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

In Emacs, everything looks like a service

yummymelon.com

Post reply on HN
Print view View original

111–120 of 127 posts

Re: In Emacs, everything looks like a service

#111

Post by spit2wind »

stormking wrote: post #94
znpy wrote: post #61

Earlier quoted context omitted.

Back in the day when i had a windows laptop for work you could just download the windows binary distribution of emacs and run that, has something changed?

Yes, running software that is not authorized can get you fired.

Depending on the job, you can likely be fired without cause anyway. You can pretend to not poke the bear, but in a place that plays power games like that, it doesn't really matter.

Presumably performance matters above all else (although it likely doesn't in such a place). If Emacs actually makes a meaningful difference, then just use it to do your work more efficiently.

You can run a batch/shell script, right? Of course you can. Would you ask for permission to write and run a script? If not (and presumably you wouldn't because that would be silly) then you shouldn't ask to run Emacs. You "own" both and take on all the "risk". There's really no difference.

But really, truly ask yourself, is whatever cause you're working towards (that is, the mission of the company) worth sacrificing your dignity for?

Re: In Emacs, everything looks like a service

#112

Post by phyzix5761 »

kleiba2 wrote: post #27

I've been an Emacs user for over 25 years. But last year I switched employers and they won't let me use it even for tasks where it would absolutely shine. Their argument is that all team members should use the same tools, and I guess that is a valid point. Unfortunately, I failed to convince my employer to make everybody else switch to Emacs. So, now I'm using lots of one-purpose tools, one for each separate task, a…

You could set the building on fire.

Re: In Emacs, everything looks like a service

#113

Post by phyzix5761 »

kleiba2 wrote: post #37
jerf wrote: post #28

Earlier quoted context omitted.

... how would they tell?

By looking at my screen? But also, why would you disobey a direct instruction from you super?

Depends what country you're in. In the US we have a culture in engineering of doing what we believe is right regardless of what the manager wants. We can afford to do that because of how highly specialized our work is and how few engineers there are (this is probably changing with AI). But in other countries managers are looking for any excuse to replace you with someone who will just nod their head and do whatever they ask.

Re: In Emacs, everything looks like a service

#114

Post by tmtvl »

smitty1e wrote: post #4
mimo84 wrote: post #3

I have been using emacs for the past couple of years. Started because I wanted to try out org mode and stayed for the extreme flexibility it offers.

I've been on spacemacs.org for a while, but since I've got a Keychron G6 Pro where I can reprogram the caps lock, I'm going to try out some hard-core init.el stylings. Suggestions welcome.

Assuming you're on GNU/Linux:

  (setq read-process-output-max
        (with-temp-buffer
          (insert-file-contents "/proc/sys/fs/pipe-max-size")
          (string-to-number (buffer-string))))

Re: In Emacs, everything looks like a service

#115

Post by convolvatron »

wtetzner wrote: post #71
convolvatron wrote: post #53

Earlier quoted context omitted.

that seems backwards to me. one of the primary constraints in language development is the OS api. programs that don't interact with the world are increasingly less interesting, and you really have to work hard and be clever to change the file and its semantics, the socket, or the thread. these things have sharp edges and tend to be leaky.

> that seems backwards to me I'm not sure I completely understand which part you find backwards. Do you mean merging language runtimes and the OS is a bad idea, or that you think merging them would lead to more innovation? I can see an argument for both (in terms of innovation), but being able to run only one language environment on a computer at a given time would make it much harder and heavy weight to use new lang…

I certainly see that the OS interface is limit to language innovation in that it assumes a lot the things I mentioned, and these tend to get shoehorned in and turn into a series layer violations to poke through all the needed flags and controls.

we definitely gain a lot of acceleration from having a common substrate, but it acts a constraint.

virtual machines are really a good out, whether that's a hardware isolation layer, or just a software abstraction. I think the view that the hypervisors present (simple virtio style devices) are maybe a better canonical OS interface than the sprawling syscall+library model.

but sure, unless I wanted to develop a language and runtime that _really_ looked different, I would try to paper over posix to the degree possible.

Re: In Emacs, everything looks like a service

#116

Post by [deleted] »

kleiba2 wrote: post #27

I've been an Emacs user for over 25 years. But last year I switched employers and they won't let me use it even for tasks where it would absolutely shine. Their argument is that all team members should use the same tools, and I guess that is a valid point. Unfortunately, I failed to convince my employer to make everybody else switch to Emacs. So, now I'm using lots of one-purpose tools, one for each separate task, a…

[deleted]

Re: In Emacs, everything looks like a service

#117

Post by jimbokun »

masfoobar wrote: post #34
kleiba2 wrote: post #27

I've been an Emacs user for over 25 years. But last year I switched employers and they won't let me use it even for tasks where it would absolutely shine. Their argument is that all team members should use the same tools, and I guess that is a valid point. Unfortunately, I failed to convince my employer to make everybody else switch to Emacs. So, now I'm using lots of one-purpose tools, one for each separate task, a…

At a company I work for, they are doing various changes (and control) over the software we install as we transition to a larger company. I believe they are using Microsoft Intune so they can allow/deny what can be installed. I have not updated my laptop (or got a new one) because I am concerned they will not allow me to install or continue to use Emacs. Honestly, I can vision how that conversation goes:- [manager]: H…

Start sending out your resume and reaching out to your network about other jobs.

Any company that anally controls every last software developers can install is a dead man walking. At least the software development part of the company.

Getting up to speed on new tools and new technologies is essential to the job of software development. Projects will grind to a halt and fail to deliver, but the management will never understand the InTune lockdown is the cause.

Re: In Emacs, everything looks like a service

#118

Post by jimbokun »

stormking wrote: post #94
znpy wrote: post #61

Earlier quoted context omitted.

Back in the day when i had a windows laptop for work you could just download the windows binary distribution of emacs and run that, has something changed?

Yes, running software that is not authorized can get you fired.

Any company that locks down the software developers can install is dead already.

Re: In Emacs, everything looks like a service

#119

Post by jimbokun »

tom_alexander wrote: post #35
wtetzner wrote: post #33

Earlier quoted context omitted.

> Their argument is that all team members should use the same tools, and I guess that is a valid point. Why is that a valid point?

In my case, I am a very senior member of my team so 25-50% of each day is spent helping and/or teaching teammates. In situations like that, it is useful to be deeply familiar with the tools that your teammates are using so you can tell them exactly what to do. For example, if I'm teaching a new hire to set up their vscode it is not very helpful to tell them "now you need to activate the python venv". It is much more…

That’s very dangerous,

The only truth is running the tools from the shell. Plugins are great conveniences and productivity enhancers. But if your devs can’t use the command line to build your software, you need to stop everything and teach them that.

Now if you want to have a standard tool set that you provide documentation for and support, then if anyone uses a different tool they are on their own. That’s perfectly fine.

But if you don’t trust your developers enough to choose their own tools, how can you trust them to deliver important software for your company?

Re: In Emacs, everything looks like a service

#120

Post by jimbokun »

BeetleB wrote: post #85
tom_alexander wrote: post #35

Earlier quoted context omitted.

In my case, I am a very senior member of my team so 25-50% of each day is spent helping and/or teaching teammates. In situations like that, it is useful to be deeply familiar with the tools that your teammates are using so you can tell them exactly what to do. For example, if I'm teaching a new hire to set up their vscode it is not very helpful to tell them "now you need to activate the python venv". It is much more…

I can somewhat sympathize - I guess the debatable aspect is to what extent should you teach? If someone knows no development tools, then yes, it is good if someone in the team knows Visual Studio Code and can guide them. In my previous job, another senior person knew it and helped out (VSCode was not mandated, and they were free to use some other tool). I tend to focus on training people on the concepts (code navigat…

That sounds lovely and a much more adult work environment than locking down everyone’s laptop.
Post reply on HN