That explains why Windows NT and OS X never got anywhere, considering that one was based on Mach and the other actually uses Mach.
Now, in Windows NT and OS X all the modules ran in the same address space. But they didn't call each other directly. They used the same generic messaging API that modules would from user space, there's just wasn't less overhead in passing the messages. But those examples are ancient history.
Not sure what "modules" you're referring to, but if you're referring to "modules" such as network protocols and file systems in OS X, they most definitely are called directly from the system call layer. Go take a look at the kern, net, and vfs directories of XNU, as well as the netinet directory of XNU and the source to the FAT file system kernel module for examples of code that plugs into the BSD-flavored socket layer and VFS mechanism.
As for the drivers they sit atop, those are called by Boring Old Procedure Calls (and method calls, given that IOKit uses a restricted flavor of C++), not by Mach message passing.
As far as I know, network protocols, file systems, and network and storage device drivers work similarly in NT.
Great, can we agree now that not much is something and not nothing?
Sure, if we'll also agree that "[introducing] (un)loadable modules" to a monolithic kernel "to address maintainability and extendability" does not in the least make that kernel any closer to a microkernel (because, in fact, it doesn't).
In other news Thylacines and Jackals have nothing to do with each other, except they both look like canids and fill similar ecological niches. Apples and oranges . . .
In other other news, Felis catus and Loxodonta africana have nothing to do with each other, except that they have four legs and bear live young.
Srsly, "both are kernels" and "both let you load and unload stuff" isn't much of an ecological niche. True microkernels (not "hybrid kernels" like the NT kernel or XNU) and monolithic kernels (with our without loadable modules) are sufficiently different from one another than "you can add or remove stuff at run time" isn't much in the way of commonality.
I can't find the article now. It was years ago. Perhaps I misunderstood it. But I think it meant something like:
Microkernels allow non-fundamental features (such as drivers for hardware that is not connected or not in use) to be loaded and unloaded at will. This is mostly achievable on Linux, through modules.
That's more like "mechanisms X or Y both allow Z to be accomplished"; the only thing that says X and Y have to do with one another is that they both allow Z to be accomplished, which isn't that much.
I'm sure you're right, though they have something to do with micokernels. There was Linus interview from a few years back explaining his preference for the monolithic approach, and he explained that modules were introduced to give most of the benefits of the microkernel, without the drawbacks.
I'd have to see that interview to believe that's exactly what he said. In this essay by him, he says
With the 2.0 kernel Linux really grew up a lot. This was the point that we added loadable kernel modules. This obviously improved modularity by making an explicit structure for writing modules. Programmers could work on different modules without risk of interference. I could keep control over what was written into the kernel proper. So once again managing people and managing code led to the same design decision. To keep the number of people working on Linux coordinated, we needed something like kernel modules. But from a design point of view, it was also the right thing to do.
but doesn't at all tie that to microkernels.
Loadable kernel modules in UN*Xes date back at least to SunOS 4.1.3 and AIX 3.0 in the early 1990's. I'm not sure they were introduced to compete with microkernels.
It's about 45,000 lines in Linux 3.19's arch/x86. A fair bit of that is crypto code, presumably either generally hand-optimized or using various new instructions to do various crypto calculations.
As I understand it, NeXT / OSX started with a micro-kernel philosophy and then introduced some monolithic kernel concepts to address the performance bottleneck of messaging between true micro modules.
Meanwhile Linux starts as a monolithic kernel, but introduced (un)loadable modules to address maintainability and extendability.
So if we described it as a continuum with 'pure microkernel' being a '1' and pure monolithic kernel being a '10', then OSX would be something like a '3' and Linux would be a '7'.
Loadable kernel modules have nothing to do with microkernels. A truly micro microkernel wouldn't need loadable kernel modules because all the loadable functionality would run in userland; plenty of monolithic kernels have loadable kernel modules.
And OS X is a lot further from "pure microkernel" than 3. The "monolithic kernel concepts" include "running the networking stack in the kernel, standard BSD-style", "running the file systems in the kernel, standard BSD-style", and "implementing most process and VM management operations with standard system calls in the kernel".
To add your claim that XNU does not follow any microkernel rules is simply false. XNU uses microkernel-style message passing.
XNU has system calls to allow messages to be sent between processes, including sending large amounts of data by page flipping.
It just doesn't happen to use that to implement very much of the UNIX API; it's not used to implement file I/O (that goes through ordinary BSD system calls to in-kernel file systems that are called through a BSD-style VFS) or network I/O (that goes through ordinary BSD system calls to in-kernel networking stacks that are called through a BSD-style kernel socket layer) or much of the process/thread management or VM code (that goes through ordinary system calls that end up calling Mach task, thread, and VM management calls).
It is used for communication between user processes, and for some kernel user communication, but that's the same sort of use that happens in systems with Boring Old Monolithic Kernels.
Yes, I have multiple trees for multiple projects. Why on earth would my life be better if I didn't?
Presumably you're not saying something such as "one directory tree for multiple projects is better than multiple directory trees for multiple projects"; that's just the moral equivalent of tabbed browsing vs. non-tabbed browsing, and some people quite legitimately don't find tabbed browsing to be an improvement for them.
Of course not. Every project should have their own repo. SVN, Git or Otherwise. I've seen many places that try to stick it all into one giant SVN project - and the result is that they end up using it as if it was just a network share.
Sorry, by "project" I didn't mean "software project", I meant "development project for a software project". I do not, for example, do all my libpcap work in a single directory tree; I have a tree checked out (cloned, tracking the remote repository) for remote-capturing work, and a tree checked out for directly talking to netlink rather than going through libnl, and so on.
There is precisely one person touching my repository, and that's me, so there's nobody to trip over. Other people's work is separated from my work by being on other people's machines. The ultimate goal of all of our work is to get our changes into the official common repository on the trunk or a release branch; how do branches either on my machine or in the common repository simplify this task?
How do branches make it more difficult?
More commands to type.
You want to do all your work in master and periodically push to a central server?
Yes.
I have my devs working on different branches per bug/feature because they may need to pass incomplete work between different developers depending on skillset or what layers of the application stack are being changed.
That's never come up as an issue for me, so that doesn't benefit me.
I want to keep them in a branch so the work doesn't slip into a release.
I avoid doing that by not running "git push" or "git review" until it's ready.
When their work is complete, reviewed, and tested, then we merge into a release candidate branch for client review.
So your organization's workflow is more formal than that of the projects on which I work with Git. On those projects, core developers can just check things in, and others can put up patches for review and pulling on GitHub (libpcap, tcpdump) or on Gerrit (Wireshark). Neither appear to require the contributor to create branches in their own repositories.
For you, branches per change may be useful. For me, not so much.
So "branch per bug" isn't "the right way to work with Git", it's merely "something Git lets you do if you choose".
If your preferred workflow doesn't map to the Git model, then don't use Git.
That's not a choice I was offered, unless there's something such as "svn-git" to let me avoid using Git even when developing for a project that uses Git (i.e., using some other VCS as a front end to the master Git repository).
And I do make my workflow work with Git. Said workflow avoids "git branch", as it's just extra keystrokes to type.
Over the years I have often found that having a flexible worfklow and allowing it to fit the capabilities of the tools being leveraged often introduces more efficient ways of working that I never would have otherwise considered.
Unless the workflow ends up trying to sleep in Procrustes' bed. Personally, I prefer more flexible tools.
Without branching, you can only have branch-like behavior by having multiple checkouts.
You say that as if it were a bad thing.
Yes, I have multiple trees for multiple projects. Why on earth would my life be better if I didn't?
Presumably you're not saying something such as "one directory tree for multiple projects is better than multiple directory trees for multiple projects"; that's just the moral equivalent of tabbed browsing vs. non-tabbed browsing, and some people quite legitimately don't find tabbed browsing to be an improvement for them.
And when you go to resolve those (at least in Git) you will still be doing a merge operation that is identical to merging a branch.
A "merge operation" that I actually bother to notice is what happens if somebody else changed some stuff in ways that collide with my changes. If that happens, it's my job to figure out what to do - including "discard my work because their changes do it better" or "discard my changes because their changes make my changes no longer necessary".
How would branches make a positive difference there?
When you have multiple people touching the same project, branching helps keep people's work separated so they aren't tripping over each other,
There is precisely one person touching my repository, and that's me, so there's nobody to trip over. Other people's work is separated from my work by being on other people's machines. The ultimate goal of all of our work is to get our changes into the official common repository on the trunk or a release branch; how do branches either on my machine or in the common repository simplify this task?
and merging provides a place for reviewing and synchronizing changes across different efforts.
Either the merge produces no conflicts - or it produces conflicts, in which case I have to resolve them, as per the above. Again, how do branches improve things here?
Event CVS and SVN have branching because it is useful.
Yes, but "having a branch for fixes to a stable release line", to keep feature work for the next release separate from fixes that go into stable release lines (possibly backported from the trunk), is different from "branching for every change you're working on". The former is useful to the project; I've yet to see any scenario in which the latter is useful.
(And, yes, I've worked at a company where you'd check your fixes into a CVS or SVN branch and have somebody else merge it with the trunk. Perhaps it worked for the organization, but it was just a nuisance for me. I did most of my work on a checked-out-from-the-trunk tree, and created the branch when it was time to submit.)
You are complaining that you refuse to use one of the very key features of Git, and that somehow that refusal on your part means that Git is hard to use.
No, I'm complaining that fans of Git seem to think that, because they believe that some particular way of using Git happens to work better for them, it's the Right Answer For Everybody.
I do. I don't want to use any dev branches, as they provide no obvious benefit to me, so I don't use any.
Well if you don't want to branch, then you're arbitrarily enforcing a condition on yourself that makes things far more difficult then they need to be.
If you insist on branching, you're arbitrarily enforcing a condition on yourself.
So why does arbitrarily choosing to work on a branch make things easier? Please give explicit examples of the downside of not explicitly creating branches.
About 20 years ago, I worked for a company which I shall not name, which used CVS as its source repository. All of the developers' home directories were NFS mounted from a central Network Appliance shared storage
...
One day, the NA disk crashed. I don't know if it was a RAID or what,
It was a NetApp box, so it used RAID 4 (and had more than one disk - the minimum was 2 disks). Perhaps the failure was something more than just a single-disk failure, as a single-disk failure shouldn't have lost the data.
Sounds to me like you try to make huge complex commits. Try rethinking your work as smaller modular commits. It makes life so much easier to do diffs and handling complex branch/merging behaviors.
The commits I do are "what's necessary to fix the problem". Perhaps that means that change A depends on change B, which depends on change C, and if none of those changes represent a regression, I do them as separate commits, pushing each one upstream as soon as the commit is done.
But what does that have to do with this "branch early, branch often" stuff I keep hearing from Git fans?
And use as many dev branches as you want in Git.
I do. I don't want to use any dev branches, as they provide no obvious benefit to me, so I don't use any.
You can always cherry pick which changes you want to bring over into your master/release branch.
If I didn't want to bring them over, I wouldn't have committed them in the first place.
Because you're not used to thinking about source code the way Git thinks about source code. Git is very much like a database from a usability standpoint
That's probably a significant part of the problem.:-)
Branch per bug? Why not just do the bug fix, and commit it after you've tested the fix?
What if it takes multiple commits to fix a bug
I.e., you tested the fix, and committed it, but it wasn't good enough and you needed to do some more fixing?
What if you want to switch away to a different branch to work on something else without losing where you're at?
Separate source trees in separate directories. I occasionally use "git stash", but the problems with that are 1) with too many stack entries or too-old stack entries, I lose context (so I'd be better off doing the work in a separate directory) and 2) on the occasions when I've managed to get my local repository in some weird state where it's not obvious how to fix it, doing my usual "clone another tree, move my changes over to that tree, and then nuke the tree with the messed-up repository from orbit, just to be sure" strategy loses the stashed stuff, so I try to use "git stash" only for 1) checking the behavior of the code without the fix I'm working on and 2) doing some relatively quick fix in the tree so that the stashed changes don't get forgotten.
You have to understand the data-structure, how files, directories and commits are all content-addressable objects. The linkage of the commits by means of their id's must be understood.
Git: the best file system anybody ever confused with a version control system.:-)
constitutes a "law... abridging the freedom of speech
Well, it only abridges if there is a punishment or consequence for doing so. The headline says "demands". Demands usually contain threats, otherwise they're request. If there is a threat, then of course it's an abridgement.
But that doesn't mean that the USPTO has threatened to break the kneecaps of the EFF's lawyers, for example. They might just be threatening to toss the EFF's document into the circular file, i.e. demanding that they change the document if it's not to be ignored.
I.e., it would have to be a "threat" in the sense of the the OED's definition of "threat", where there's some form of harm worse than "being ignored" to be an abridgement.
if it is, the protest will probably be carefully filed away in the roughly-cylindrical filing cabinet on the side of the desk of the person at the Patent Office receiving it.
Which is a completely legitimate response to an illegitimate filing.
I.e., a threat to toss the document into the circular file is a legitimate response.
(c) Protest and Pre-Issuance Opposition.— The Director shall establish appropriate procedures to ensure that no protest or other form of pre-issuance opposition to the grant of a patent on an application may be initiated after publication of the application without the express written consent of the applicant.
into the U.S. Code constitutes a "law... abridging the freedom of speech, or of the press; or the right of the people peaceably to assemble, and to petition the Government for a redress of grievances."?
You can still "petition the Government for a redress of grievances", just not in the form of a "protest or other form of pre-issuance opposition to the grant of a patent"; if it is, the protest will probably be carefully filed away in the roughly-cylindrical filing cabinet on the side of the desk of the person at the Patent Office receiving it. It's not as if you're going to be taken out and shot if, for example, you write a letter to the President complaining about the patent being applied for, or publish an editorial opposing the patent, or....
I don't think you'll ever find it. A Chevy Malibu was either stolen for a joy ride, which generally the car is found near immediately or after a few days
It's your own code you'd mainly have to worry about.
But, alas, I always seem to get called in to debug code from other folks.
You probably don't get called in to debug endianness issues in any TCP stacks in portable general-purpose non-hobby OSes; if so, I'd look a bit askance at the developer team for that OS.
My point is that worrying about porting server OSes for PPC machines is not something worth worrying about, as they've either already been ported (Linux) or, if they ever get ported, are likely only to be ported to little-endian machines using compilers that aren't going to differ between platforms on the signedness of char (Windows). What you worry about there is third-party applications.
A simple recompile won't do it . . . some programs, like your TCP/IP stack have dependencies on Endianess. IBM's POWER has been traditionally Big Endian. Linux is mostly Little Endian. There are C macros, ntoh() and hton() that do the required byte swapping for you . . . if you remember to use them!
The TCP/IP stack you're using was probably originally written by people working on a little-endian machine - VAX (if it's the BSD stack or a derivative thereof) or x86 (if it's the Linux stack) - so that's not the code to worry about; it has the relevant ntoh[sl]()/hton[sl]() calls already.
It's your own code you'd mainly have to worry about. I.e., Linux should pretty much Just Work (it runs on 32-bit and 64-bit PowerPC, and it sounds as if support for little-endian mode is being added), but it's the third-party software that's might be an issue.
Yup. I have the impression that the South Park line from which I derived my response was mocking the business model of dot-com-boom startups, rather a lot of which failed.
Maybe for a bricks and mortar business, but online businesses have nearly no start up cost at all. All you need is a cheap web host and you're set. Learn to code and maintain it by yourself to keep start-up costs low. Once you have made a profit, then you can buy specialised hardware or additional things for your business.
The "Nobel prize of computing"? Jeez, has the author been in a space capsule traveling back from Mars for the past decade? The Nobel prize isn't what it used to be
Confusingly, the Nobel Prize Web site speaks both of "the Nobel prize" and "the Nobel prizes". The latter is a better phrase, as there isn't a single "Nobel Prize", there are Nobel prizes in a number of different fields.
- if it ever was in the first place. It's a damaged, discredited brand, like Paula Deen, Best Buy, or "hands up don't shoot". I'd avoid using the phrase in the future.
I've not heard that, say, the Nobel Prizes in scientific fields are particularly damaged and discredited; what have you heard to indicate that, if anything? If we're talking about a technical field, "Nobel Prize in..." would presumably liken a given prize to the Nobel Prizes in physics, chemistry, and medicine, rather than to the Prizes in literature or peace (or "The Sveriges Riksbank Prize in Economic Sciences in Memory of Alfred Nobel").
Slashdot Mirror
That explains why Windows NT and OS X never got anywhere, considering that one was based on Mach and the other actually uses Mach.
Now, in Windows NT and OS X all the modules ran in the same address space. But they didn't call each other directly. They used the same generic messaging API that modules would from user space, there's just wasn't less overhead in passing the messages. But those examples are ancient history.
Not sure what "modules" you're referring to, but if you're referring to "modules" such as network protocols and file systems in OS X, they most definitely are called directly from the system call layer. Go take a look at the kern , net , and vfs directories of XNU, as well as the netinet directory of XNU and the source to the FAT file system kernel module for examples of code that plugs into the BSD-flavored socket layer and VFS mechanism.
As for the drivers they sit atop, those are called by Boring Old Procedure Calls (and method calls, given that IOKit uses a restricted flavor of C++), not by Mach message passing.
As far as I know, network protocols, file systems, and network and storage device drivers work similarly in NT.
though they have something to do with micokernels
Which isn't that much.
Great, can we agree now that not much is something and not nothing?
Sure, if we'll also agree that "[introducing] (un)loadable modules" to a monolithic kernel "to address maintainability and extendability" does not in the least make that kernel any closer to a microkernel (because, in fact, it doesn't).
In other news Thylacines and Jackals have nothing to do with each other, except they both look like canids and fill similar ecological niches. Apples and oranges . . .
In other other news, Felis catus and Loxodonta africana have nothing to do with each other, except that they have four legs and bear live young.
Srsly, "both are kernels" and "both let you load and unload stuff" isn't much of an ecological niche. True microkernels (not "hybrid kernels" like the NT kernel or XNU) and monolithic kernels (with our without loadable modules) are sufficiently different from one another than "you can add or remove stuff at run time" isn't much in the way of commonality.
I can't find the article now. It was years ago. Perhaps I misunderstood it. But I think it meant something like:
That's more like "mechanisms X or Y both allow Z to be accomplished"; the only thing that says X and Y have to do with one another is that they both allow Z to be accomplished, which isn't that much.
I'm sure you're right, though they have something to do with micokernels. There was Linus interview from a few years back explaining his preference for the monolithic approach, and he explained that modules were introduced to give most of the benefits of the microkernel, without the drawbacks.
I'd have to see that interview to believe that's exactly what he said. In this essay by him, he says
but doesn't at all tie that to microkernels.
Loadable kernel modules in UN*Xes date back at least to SunOS 4.1.3 and AIX 3.0 in the early 1990's. I'm not sure they were introduced to compete with microkernels.
> There are over 100 separate ... speedups
The last time I looked, which was quite a few years ago TBH, the BSDs have, IIRC, less than 100 lines of x86 assembly, in the bootstrap.
From relatively-recent FreeBSD:
It's about 45,000 lines in Linux 3.19's arch/x86. A fair bit of that is crypto code, presumably either generally hand-optimized or using various new instructions to do various crypto calculations.
As I understand it, NeXT / OSX started with a micro-kernel philosophy and then introduced some monolithic kernel concepts to address the performance bottleneck of messaging between true micro modules.
Meanwhile Linux starts as a monolithic kernel, but introduced (un)loadable modules to address maintainability and extendability.
So if we described it as a continuum with 'pure microkernel' being a '1' and pure monolithic kernel being a '10', then OSX would be something like a '3' and Linux would be a '7'.
Loadable kernel modules have nothing to do with microkernels. A truly micro microkernel wouldn't need loadable kernel modules because all the loadable functionality would run in userland; plenty of monolithic kernels have loadable kernel modules.
And OS X is a lot further from "pure microkernel" than 3. The "monolithic kernel concepts" include "running the networking stack in the kernel, standard BSD-style", "running the file systems in the kernel, standard BSD-style", and "implementing most process and VM management operations with standard system calls in the kernel".
To add your claim that XNU does not follow any microkernel rules is simply false. XNU uses microkernel-style message passing.
XNU has system calls to allow messages to be sent between processes, including sending large amounts of data by page flipping.
It just doesn't happen to use that to implement very much of the UNIX API; it's not used to implement file I/O (that goes through ordinary BSD system calls to in-kernel file systems that are called through a BSD-style VFS) or network I/O (that goes through ordinary BSD system calls to in-kernel networking stacks that are called through a BSD-style kernel socket layer) or much of the process/thread management or VM code (that goes through ordinary system calls that end up calling Mach task, thread, and VM management calls).
It is used for communication between user processes, and for some kernel user communication, but that's the same sort of use that happens in systems with Boring Old Monolithic Kernels.
Of course not. Every project should have their own repo. SVN, Git or Otherwise. I've seen many places that try to stick it all into one giant SVN project - and the result is that they end up using it as if it was just a network share.
Sorry, by "project" I didn't mean "software project", I meant "development project for a software project". I do not, for example, do all my libpcap work in a single directory tree; I have a tree checked out (cloned, tracking the remote repository) for remote-capturing work, and a tree checked out for directly talking to netlink rather than going through libnl, and so on.
How do branches make it more difficult?
More commands to type.
You want to do all your work in master and periodically push to a central server?
Yes.
I have my devs working on different branches per bug/feature because they may need to pass incomplete work between different developers depending on skillset or what layers of the application stack are being changed.
That's never come up as an issue for me, so that doesn't benefit me.
I want to keep them in a branch so the work doesn't slip into a release.
I avoid doing that by not running "git push" or "git review" until it's ready.
When their work is complete, reviewed, and tested, then we merge into a release candidate branch for client review.
So your organization's workflow is more formal than that of the projects on which I work with Git. On those projects, core developers can just check things in, and others can put up patches for review and pulling on GitHub (libpcap, tcpdump) or on Gerrit (Wireshark). Neither appear to require the contributor to create branches in their own repositories.
For you, branches per change may be useful. For me, not so much.
So "branch per bug" isn't "the right way to work with Git", it's merely "something Git lets you do if you choose".
If your preferred workflow doesn't map to the Git model, then don't use Git.
That's not a choice I was offered, unless there's something such as "svn-git" to let me avoid using Git even when developing for a project that uses Git (i.e., using some other VCS as a front end to the master Git repository).
And I do make my workflow work with Git. Said workflow avoids "git branch", as it's just extra keystrokes to type.
Over the years I have often found that having a flexible worfklow and allowing it to fit the capabilities of the tools being leveraged often introduces more efficient ways of working that I never would have otherwise considered.
Unless the workflow ends up trying to sleep in Procrustes' bed. Personally, I prefer more flexible tools.
Without branching, you can only have branch-like behavior by having multiple checkouts.
You say that as if it were a bad thing.
Yes, I have multiple trees for multiple projects. Why on earth would my life be better if I didn't?
Presumably you're not saying something such as "one directory tree for multiple projects is better than multiple directory trees for multiple projects"; that's just the moral equivalent of tabbed browsing vs. non-tabbed browsing, and some people quite legitimately don't find tabbed browsing to be an improvement for them.
And when you go to resolve those (at least in Git) you will still be doing a merge operation that is identical to merging a branch.
A "merge operation" that I actually bother to notice is what happens if somebody else changed some stuff in ways that collide with my changes. If that happens, it's my job to figure out what to do - including "discard my work because their changes do it better" or "discard my changes because their changes make my changes no longer necessary".
How would branches make a positive difference there?
When you have multiple people touching the same project, branching helps keep people's work separated so they aren't tripping over each other,
There is precisely one person touching my repository, and that's me, so there's nobody to trip over. Other people's work is separated from my work by being on other people's machines. The ultimate goal of all of our work is to get our changes into the official common repository on the trunk or a release branch; how do branches either on my machine or in the common repository simplify this task?
and merging provides a place for reviewing and synchronizing changes across different efforts.
Either the merge produces no conflicts - or it produces conflicts, in which case I have to resolve them, as per the above. Again, how do branches improve things here?
Event CVS and SVN have branching because it is useful.
Yes, but "having a branch for fixes to a stable release line", to keep feature work for the next release separate from fixes that go into stable release lines (possibly backported from the trunk), is different from "branching for every change you're working on". The former is useful to the project; I've yet to see any scenario in which the latter is useful.
(And, yes, I've worked at a company where you'd check your fixes into a CVS or SVN branch and have somebody else merge it with the trunk. Perhaps it worked for the organization, but it was just a nuisance for me. I did most of my work on a checked-out-from-the-trunk tree, and created the branch when it was time to submit.)
You are complaining that you refuse to use one of the very key features of Git, and that somehow that refusal on your part means that Git is hard to use.
No, I'm complaining that fans of Git seem to think that, because they believe that some particular way of using Git happens to work better for them, it's the Right Answer For Everybody.
Well if you don't want to branch, then you're arbitrarily enforcing a condition on yourself that makes things far more difficult then they need to be.
If you insist on branching, you're arbitrarily enforcing a condition on yourself.
So why does arbitrarily choosing to work on a branch make things easier? Please give explicit examples of the downside of not explicitly creating branches.
About 20 years ago, I worked for a company which I shall not name, which used CVS as its source repository. All of the developers' home directories were NFS mounted from a central Network Appliance shared storage
...
One day, the NA disk crashed. I don't know if it was a RAID or what,
It was a NetApp box, so it used RAID 4 (and had more than one disk - the minimum was 2 disks). Perhaps the failure was something more than just a single-disk failure, as a single-disk failure shouldn't have lost the data.
Sounds to me like you try to make huge complex commits. Try rethinking your work as smaller modular commits. It makes life so much easier to do diffs and handling complex branch/merging behaviors.
The commits I do are "what's necessary to fix the problem". Perhaps that means that change A depends on change B, which depends on change C, and if none of those changes represent a regression, I do them as separate commits, pushing each one upstream as soon as the commit is done.
But what does that have to do with this "branch early, branch often" stuff I keep hearing from Git fans?
And use as many dev branches as you want in Git.
I do. I don't want to use any dev branches, as they provide no obvious benefit to me, so I don't use any.
You can always cherry pick which changes you want to bring over into your master/release branch.
If I didn't want to bring them over, I wouldn't have committed them in the first place.
Because you're not used to thinking about source code the way Git thinks about source code. Git is very much like a database from a usability standpoint
That's probably a significant part of the problem. :-)
Branch per bug? Why not just do the bug fix, and commit it after you've tested the fix?
What if it takes multiple commits to fix a bug
I.e., you tested the fix, and committed it, but it wasn't good enough and you needed to do some more fixing?
What if you want to switch away to a different branch to work on something else without losing where you're at?
Separate source trees in separate directories. I occasionally use "git stash", but the problems with that are 1) with too many stack entries or too-old stack entries, I lose context (so I'd be better off doing the work in a separate directory) and 2) on the occasions when I've managed to get my local repository in some weird state where it's not obvious how to fix it, doing my usual "clone another tree, move my changes over to that tree, and then nuke the tree with the messed-up repository from orbit, just to be sure" strategy loses the stashed stuff, so I try to use "git stash" only for 1) checking the behavior of the code without the fix I'm working on and 2) doing some relatively quick fix in the tree so that the stashed changes don't get forgotten.
Oh! Hi, all you other frogs in here.
Is this water getting warmer?
Not warm enough if none of them have jumped yet.
(Time for that metaphor to die, methinks.)
You have to understand the data-structure, how files, directories and commits are all content-addressable objects. The linkage of the commits by means of their id's must be understood.
Git: the best file system anybody ever confused with a version control system. :-)
constitutes a "law ... abridging the freedom of speech
Well, it only abridges if there is a punishment or consequence for doing so. The headline says "demands". Demands usually contain threats, otherwise they're request. If there is a threat, then of course it's an abridgement.
But that doesn't mean that the USPTO has threatened to break the kneecaps of the EFF's lawyers, for example. They might just be threatening to toss the EFF's document into the circular file, i.e. demanding that they change the document if it's not to be ignored.
I.e., it would have to be a "threat" in the sense of the the OED's definition of "threat", where there's some form of harm worse than "being ignored" to be an abridgement.
if it is, the protest will probably be carefully filed away in the roughly-cylindrical filing cabinet on the side of the desk of the person at the Patent Office receiving it.
Which is a completely legitimate response to an illegitimate filing.
I.e., a threat to toss the document into the circular file is a legitimate response.
I think they need to have a look at the 1st amendment to the constitution.
They ARE, in fact, bound by that
So are you saying that whatever law put 35 U.S. Code section 122(c):
into the U.S. Code constitutes a "law ... abridging the freedom of speech, or of the press; or the right of the people peaceably to assemble, and to petition the Government for a redress of grievances."?
You can still "petition the Government for a redress of grievances", just not in the form of a "protest or other form of pre-issuance opposition to the grant of a patent"; if it is, the protest will probably be carefully filed away in the roughly-cylindrical filing cabinet on the side of the desk of the person at the Patent Office receiving it. It's not as if you're going to be taken out and shot if, for example, you write a letter to the President complaining about the patent being applied for, or publish an editorial opposing the patent, or....
Protests against patents are discussed in more detail by 37 U.S. Code section 1.291.
I don't think you'll ever find it. A Chevy Malibu was either stolen for a joy ride, which generally the car is found near immediately or after a few days
Found on what planet?
It's your own code you'd mainly have to worry about.
But, alas, I always seem to get called in to debug code from other folks.
You probably don't get called in to debug endianness issues in any TCP stacks in portable general-purpose non-hobby OSes; if so, I'd look a bit askance at the developer team for that OS.
My point is that worrying about porting server OSes for PPC machines is not something worth worrying about, as they've either already been ported (Linux) or, if they ever get ported, are likely only to be ported to little-endian machines using compilers that aren't going to differ between platforms on the signedness of char (Windows). What you worry about there is third-party applications.
A simple recompile won't do it . . . some programs, like your TCP/IP stack have dependencies on Endianess. IBM's POWER has been traditionally Big Endian. Linux is mostly Little Endian. There are C macros, ntoh() and hton() that do the required byte swapping for you . . . if you remember to use them!
The TCP/IP stack you're using was probably originally written by people working on a little-endian machine - VAX (if it's the BSD stack or a derivative thereof) or x86 (if it's the Linux stack) - so that's not the code to worry about; it has the relevant ntoh[sl]()/hton[sl]() calls already.
It's your own code you'd mainly have to worry about. I.e., Linux should pretty much Just Work (it runs on 32-bit and 64-bit PowerPC, and it sounds as if support for little-endian mode is being added), but it's the third-party software that's might be an issue.
Yup. I have the impression that the South Park line from which I derived my response was mocking the business model of dot-com-boom startups, rather a lot of which failed.
Maybe for a bricks and mortar business, but online businesses have nearly no start up cost at all. All you need is a cheap web host and you're set. Learn to code and maintain it by yourself to keep start-up costs low. Once you have made a profit, then you can buy specialised hardware or additional things for your business.
What if you broke out United States statistics by race? I wonder what you'd find.
The Fine ETS Study discusses that starting at page 37.
The "Nobel prize of computing"? Jeez, has the author been in a space capsule traveling back from Mars for the past decade? The Nobel prize isn't what it used to be
Confusingly, the Nobel Prize Web site speaks both of "the Nobel prize" and "the Nobel prizes". The latter is a better phrase, as there isn't a single "Nobel Prize", there are Nobel prizes in a number of different fields.
- if it ever was in the first place. It's a damaged, discredited brand, like Paula Deen, Best Buy, or "hands up don't shoot". I'd avoid using the phrase in the future.
I've not heard that, say, the Nobel Prizes in scientific fields are particularly damaged and discredited; what have you heard to indicate that, if anything? If we're talking about a technical field, "Nobel Prize in..." would presumably liken a given prize to the Nobel Prizes in physics, chemistry, and medicine, rather than to the Prizes in literature or peace (or "The Sveriges Riksbank Prize in Economic Sciences in Memory of Alfred Nobel").