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

Bzr is dying; Emacs needs to move

lists.gnu.org

Post reply on HN
Print view View original

291–300 of 317 posts

Re: Bzr is dying; Emacs needs to move

#291

Post by dredmorbius »

codereflection wrote: post #254
chebucto wrote: post #162

Earlier quoted context omitted.

As he said, 'more than Emacs is at stake here.'.[1] I presume this refers to Bazaar's status as part of the GNU project, and that RMS did not want to write off part of GNU without being certain he needed to. Regardless, he has since OKd the switch from bzr: I don't insist that Emacs should stay with bzr. I chose to support bzr because it was still a contender at the time. [2] [1] https://lists.gnu.org/archive/html/em…

I think Stallman is being reasonable here.

He's not always an unreasonable man.

https://paragraft.wordpress.com/2008/05/01/progress-and-the-...

Re: Bzr is dying; Emacs needs to move

#292

Post by [deleted] »

Crito wrote: post #184
chx wrote: post #161

Earlier quoted context omitted.

> the desire to support arbitrary workflows. Now I am laughing and laughing bitterly. git supports one workflow -- the massively decentralized one. To this day you can't have a simple workflow with git, the one that cvs/svn supported and practically all small project would benefit from, the one that bzr calls a bound branch. git , I believe , is the textbook case of what the opposite of a user friendly UI is. command…

> "To this day you can't have a simple workflow with git, the one that cvs/svn supported and practically all small project would benefit from" What? Of course you can. I've worked on teams that did it. You are talking total rubbish.

[deleted]

Re: Bzr is dying; Emacs needs to move

#293

Post by valleyer »

empthought wrote: post #185
gillianseed wrote: post #140

Earlier quoted context omitted.

From what I understand, the Mach kernel which is now used in XNU is not the Mach micro kernel (3.0 >) but based upon the pre-micro-kernel 2.5 version of Mach. I'm not sure where I read this originally but I just googled this source which seems to back it up: http://www.roughlydrafted.com/0506.mk3.html

According to the Apple docs XNU is based on Mach 3.0. https://developer.apple.com/library/mac/documentation/Darwin...

That's misleading. Apple merged in a bunch of Mach 3 code but still maintains the architecture of Mach 2.5 (i.e., Mach + BSD both running in supervisor mode in one big monolith; no BSD server; xnu is not a microkernel…).

Re: Bzr is dying; Emacs needs to move

#294

Post by valleyer »

Demiurge wrote: post #228
comex wrote: post #217

Earlier quoted context omitted.

No, they are not. A crash in a kext causes a kernel panic.

You are right. An actual crash in kext causes kernel panic. I think I read that this is was possible, but I can't find how, and when, right now. The common thing that I'm thinking of is just voluntary error (exception) handling in kexts and reloading of kext on their own. There is some isolation and benefit to it. Edit: ok, I just figured out my source of confusion. IOKit allows userspace drivers, which can crash wit…

IOKit allows communication between kexts and userland. You could call that "userland drivers", but it's not like you can write only userland code to implement a driver.

Re: Bzr is dying; Emacs needs to move

#295

Post by valleyer »

Demiurge wrote: post #216
justincormack wrote: post #205

Earlier quoted context omitted.

Because building and maintaining a competitive OS is a huge effort, and FreeBSD has lots of cool stuff which they can't use...

It's a huge effort worth that seems to be paying off quite handily. XNU seems like a competitive edge over the monolith FreeBSD, as far as desktop and mobile OS is concerned. FreeBSD has plenty of cool stuff, but in a completely different domain.

> XNU seems like a competitive edge over the monolith FreeBSD,

xnu is also a monolithic kernel, just with some nice message-passing primitives. Think Mach 2.5.

Re: Bzr is dying; Emacs needs to move

#296

Post by chx »

StavrosK wrote: post #169
wirrbel wrote: post #91

Earlier quoted context omitted.

The success of git is - apart from the speed - related with its property of being the "stupid content tracker". Git's architecture is a simple bottom-up engineering approach. The user interface (porcellain) builts upon a conceptually simple core (plumbing). Other VCS have defined nice UI which where then implemented by a core that depends on the UI. This top-down approach means that the core components can suddenly b…

> It turns out however that Git is really easy to grasp. Please write something to explain it. I must be pretty dumb, because I don't get it, even after reading about ten explanatory texts.

Here http://www.sbf5.com/~cduan/technical/git/ this is the only way to understand git.

Re: Bzr is dying; Emacs needs to move

#297

Post by makomk »

Sssnake wrote: post #245
IgorPartola wrote: post #133

Earlier quoted context omitted.

That's a simplistic view. First, the GNU project is very much alive: the GNU tools are used in a huge number of operating systems and are installed on a staggering number of devices. I would bet that the system you are writing this comment from is running thanks to the GNU software. Second, it is debatable whether sticking to Hurd was a good or a bad idea technically . Imagine if Stallman and co. managed to convince…

>the GNU tools are used in a huge number of operating systems You mean linux? That isn't a huge number. >and are installed on a staggering number of devices The staggering number of devices you refer to almost exclusively run busybox or one of the similar projects. GNU software is hugely bloated and not a good choice for embedded systems. >Second, it is debatable whether sticking to Hurd was a good or a bad idea tech…

Last I heard a lot of users of Solaris and other Unixes often also use the GNU tools, though those are generally dying out in favour of Linux anyway.

Re: Bzr is dying; Emacs needs to move

#298

Post by josephlord »

Sssnake wrote: post #245
IgorPartola wrote: post #133

Earlier quoted context omitted.

That's a simplistic view. First, the GNU project is very much alive: the GNU tools are used in a huge number of operating systems and are installed on a staggering number of devices. I would bet that the system you are writing this comment from is running thanks to the GNU software. Second, it is debatable whether sticking to Hurd was a good or a bad idea technically . Imagine if Stallman and co. managed to convince…

>the GNU tools are used in a huge number of operating systems You mean linux? That isn't a huge number. >and are installed on a staggering number of devices The staggering number of devices you refer to almost exclusively run busybox or one of the similar projects. GNU software is hugely bloated and not a good choice for embedded systems. >Second, it is debatable whether sticking to Hurd was a good or a bad idea tech…

GNU tools were often used on other OSes too including Solaris and other commercial Unixes but also Windows under Cygwin. Particularly GCC, make etc. but also command line tools such as grep where the default platform versions were often not as feature rich. I didn't use those platforms so others will remember and know better but I don't think huge was an obviously wrong description.

Re: Bzr is dying; Emacs needs to move

#299

Post by StavrosK »

chx wrote: post #296
StavrosK wrote: post #169

Earlier quoted context omitted.

> It turns out however that Git is really easy to grasp. Please write something to explain it. I must be pretty dumb, because I don't get it, even after reading about ten explanatory texts.

Here http://www.sbf5.com/~cduan/technical/git/ this is the only way to understand git.

That's a great explanation, thank you!

Re: Bzr is dying; Emacs needs to move

#300

Post by r0muald »

falcolas wrote: post #59
xradionut wrote: post #42

Earlier quoted context omitted.

I hate when people say "git won the war", it sounds like an excuse to close minds and stop progress. What if "Microsoft won the war"? Or vim? Or IBM? Or Java? Or Taco Bell?

As an avid git user, I believe that git's victory against current tools does nothing to stop someone from creating a better DVCS in the future. They'll just have to identify why git won and address those points, if they want to dethrone git.

1. Linux

2. GitHub

That's it really.

Post reply on HN