On Wed, Jul 28, 2010 at 01:00:37PM -0500, Chris Turner wrote:
> elekktrett...@exemail.com.au wrote:
>> that is incompatible with everything else on the market. You're not going
>> to get Linux to change because of BSD, it's the other way around. At least
>
> man socket()
LoL :-)
> Given that's it's going to be a year until the next one, I wouldn't wait
> on any work you may want to do; a new GPT editor could be finished in less
> time, I would guess.
Doah, I haven't been a student for 5 years :)
On Thu, July 29, 2010 7:56 pm, elekktrett...@exemail.com.au wrote:
>> Yes, it's students-only. Don't wait! Start now. It'll be difficult,
>> but
>> nothing worthwhile is ever easy.
>
> So I have to be a uni student or something like that?
Yes.
http://socghop.appspot.com/document/show/gsoc_prog
:> If someone wants to write a really nice gpt partition editor that
:> pops you into vi or emacs or whatever then I would be more amendable
:> to using gpt as a default. But if all we have is command-line
:> list/add/remove junk, then no.
:
:Can you give me some pointers as for w
> If someone wants to write a really nice gpt partition editor that
> pops you into vi or emacs or whatever then I would be more amendable
> to using gpt as a default. But if all we have is command-line
> list/add/remove junk, then no.
Can you give me some pointers as for where to
> Yes, it's students-only. Don't wait! Start now. It'll be difficult, but
> nothing worthwhile is ever easy.
So I have to be a uni student or something like that?
Petr
On 28/07/10 21:58, Adam Vande More wrote:
> [...]
> It's not just that combination though. HammerFS could be used on other
> modules like gvinum, gconcat, etc, etc.
>
> I'm interested in using Dragonfly for some embedded system, but having
> more GPL stuff is essentially a non-starter for me as w
On Wed, Jul 28, 2010 at 3:31 PM, Matthew Dillon wrote:
>
>
> Urm. What's the point of a mirror if you need a third journaling
>device which itself can fail or glitch? Do you mirror the journal too?
>I have serious problems with this concept, and also with the complexity
>and the
:I still don't get your point. GPT support in the loader is not
:> assisted in any way by geom or any other similar mess.
:>
:
:The gpart class is a helper of the loader. It creates the normal gpt boot
:partition unlike the hack that exists in gpt(8)
:
:
:Also I don't see any advantage to any sof
On Wed, Jul 28, 2010 at 11:39 AM, Alex Hornung wrote:
> I absolutely don't see how forcing the I/O from N different threads
> onto 2 (events are not I/O effectively) is better than having each I/O
> maintain (mostly) it's own context. Your particular case may not
> suffer from any performance imp
Personally speaking I would prefer the lvm/dm infrastructure. There
are many reasons for this, some personal, some not.
First of all, we absolutely do not need the duplication. Having both
in the system makes no sense whatsoever. It just creates unnecessary
confusion.
I
elekktrett...@exemail.com.au wrote:
that is incompatible with everything else on the market. You're not going
to get Linux to change because of BSD, it's the other way around. At least
man socket()
On 28 July 2010 17:14, Adam Vande More wrote:
> [...]
> Well it's 3 main actually(up, down, and event threads basically), and
> depending on the module you can spawn other kernel threads to handle
> asynchronous stuff to pass off when it's ready. The design has awfully nice
> performance characte
On Wed, Jul 28, 2010 at 2:13 AM, Alex Hornung wrote:
> On 28/07/10 03:30, Adam Vande More wrote:
> > [...] although I am
> > curious to know why GEOM wasn't chosen. It's both more powerful, and
> > easier to use IMO. Some examples of that would be gmirror, glabel,
> > gstripe, HAST, etc -- all
On 28/07/10 03:30, Adam Vande More wrote:
> [...] although I am
> curious to know why GEOM wasn't chosen. It's both more powerful, and
> easier to use IMO. Some examples of that would be gmirror, glabel,
> gstripe, HAST, etc -- all easier than the Linux equivalents. The mdadm
> stuff is reliable
On Tue, Jul 27, 2010 at 9:55 PM, wrote:
> > Also, if Linux wants to import *BSD's block devices,
> > that's
> > a Linux problem, not *BSD's.
>
> I think that "some" Unix interoperability should be a long term goal for
> any Unix system. When you have a recognized standard like GPT, using it
> see
On Tue, July 27, 2010 10:55 pm, elekktrett...@exemail.com.au wrote:
>> Also, if Linux wants to import *BSD's block devices,
>> that's
>> a Linux problem, not *BSD's.
>
> I think that "some" Unix interoperability should be a long term goal for
> any Unix system. When you have a recognized standard l
> Also, if Linux wants to import *BSD's block devices,
> that's
> a Linux problem, not *BSD's.
I think that "some" Unix interoperability should be a long term goal for
any Unix system. When you have a recognized standard like GPT, using it
seems to be the right thing to do, instead of developing a
On Tue, Jul 27, 2010 at 8:44 PM, wrote:
> So, what is the real world advantage of using disklabel, that can't be
> done with GPT on 99.99% of all OS install? that is worth breaking
> compatibility with other *BSDs - each BSD implements disklabel
> differently- and other OSs like Linux - doesn't u
On Tue, Jul 27, 2010 at 7:44 PM, wrote:
>> What evidence do you have of newcomers being "more than often" turned
>> away by having to use "archaic tools"?
>
> I visit a couple of Linux forums, and while the word "DragonFly" surely
> seems to have picked up some usage in the recent months, I also
> What evidence do you have of newcomers being "more than often" turned
> away by having to use "archaic tools"?
I visit a couple of Linux forums, and while the word "DragonFly" surely
seems to have picked up some usage in the recent months, I also hear that
they go somewhere else after a brief ex
On 7/24/2010 6:47, elekktrett...@exemail.com.au wrote:
It seems that a lot of new comers get a really annoyed(and more than often
turn away altogether) with the fact that they have to use archaic programs
like disklabel to setup partitions. Wouldn't it be better to simply dump
it, and use GPT par
> Well, there are two parts to GPT. There is the partition table
> standard and then there is the BIOS support. If you mean booting
> from a GPT compatibility slice without needing the BIOS support
> then it is probably doable.
This.
I've come across a few people (Linux users wa
:
:DragonFly could really lead the way here amongst the BSDs who all use some
:version of disklabel. Can DF boot from a GPT partition? If so the next
:thing would be teaching it to boot from such a partition without a
:disklabel present.
:
:For example:
:/boot ... /dev/da0p0
:/ ... /dev/da0p1
:/us
DragonFly could really lead the way here amongst the BSDs who all use some
version of disklabel. Can DF boot from a GPT partition? If so the next
thing would be teaching it to boot from such a partition without a
disklabel present.
For example:
/boot ... /dev/da0p0
/ ... /dev/da0p1
/usr ... /dev/d
> If by dump it you mean default to GPT style partitioning, I think that is
> valid discussion. I would say yes, standardization here seems to be a net
> positive.
Yes thats what I mean.
Instead of disklabel partitions like ad0s1*, only use GPT partitions ie.
ad0p* - note the change from "s" to
On Fri, Jul 23, 2010 at 11:47 PM, wrote:
> It seems that a lot of new comers get a really annoyed(and more than often
> turn away altogether) with the fact that they have to use archaic programs
> like disklabel to setup partitions. Wouldn't it be better to simply dump
> it, and use GPT partition
It seems that a lot of new comers get a really annoyed(and more than often
turn away altogether) with the fact that they have to use archaic programs
like disklabel to setup partitions. Wouldn't it be better to simply dump
it, and use GPT partitions instead?
Petr
28 matches
Mail list logo
