Language:
switch to room list switch to menu My folders
Go to page: First ... 37 38 39 40 [41] 42 43 44 45 ... Last
[#] Sun Dec 13 2009 18:31:24 EST from Ford II @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

whole new version, but we're talking 2.6.30.9-99 to 2.6.30.9-102 
that should be a very minor change that shouldn't break anything. 
That's my beef.  I don't expect 100% backwards compatibility just a


Wanna talk beef?
2.6.30.9-102 is retarded.
what does it mean?
version 2, release 6, subhack 39, fix 9 patch 102?

[#] Sun Dec 13 2009 18:34:35 EST from Ford II @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

I don't have a problem with git, I have a problem with svn, if you're going to use svn, that's one mistake, but switching from cvs to svn is just backwards to me.

[#] Sun Dec 13 2009 21:42:19 EST from Peter Pulse @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

On my cellphone so I'll be brief.. but yea in short, NO it is not necessary to break APIs to advance a system.. the WHOLE POINT of an API is to generalize the interface between two pieces of code that were not developed together.
If you cannot change one piece withouth changing the other the your API sucks and is pointless. There are ways of doing things to allow for future expansion without breaking compatibility, a well designed API can maintain compatibility for a very long time IF the programmer has the incentive to do so.. AND IF THEY HAVE THE SKILL.

[#] Mon Dec 14 2009 08:39:36 EST from LoanShark @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

If you want stable, you use centos, and if you want to be bleeding
edge you get fedora, it's the equivalent of downloading and building
the development kernel every day, no?

then why doesn't fedora just say so, and stop making each release as a maintenance branch off of rawhide.

answer: because even bleeding edge developers need a somewhat stable base to build on top of...

[#] Mon Dec 14 2009 08:42:51 EST from LoanShark @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

well designed API can maintain compatibility for a very long time IF
the programmer has the incentive to do so.. AND IF THEY HAVE THE SKILL.


Ding ding! We have a winner.

[#] Mon Dec 14 2009 08:48:18 EST from LoanShark @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

version 2, release 6, subhack 39, fix 9 patch 102?

Well the "2.6" part became essentially meaningless quite some time ago. They stopped incrementing that part, because they no longer know how to define when a change is major enough. They just have a continuous stream of releases in the 2.6 series. So "30" is the major release, "9" is the maintenance number, and then "102" is the numbered release of Fedora's fork which is based on 30.9. Going from x-101 to x-102 might be just bugfixes, or if it's a rawhide release, might integrate a large patch that substantially changes interfaces and adds new functionality. Those sorts of things are theoretically supposed to only happen within a rawhide release, but in practice... either they don't care, or the problem might just be that that's what they wanted to do but Fedora doesn't have the same level of QA as, say, RHEL.

Did the original poster in this thread attempt to reinstall his nvidia drivers? by what means, anyway? ;)

[#] Mon Dec 14 2009 08:54:12 EST from LoanShark @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

well designed API can maintain compatibility for a very long time IF
the programmer has the incentive to do so.. AND IF THEY HAVE THE SKILL.


Except if the API under discussion is a SOAP API, in which case the answer is: there is no backwards compatibility without adding an entirely new interface, stop complaining and go away. Kind of sucks, actually: your only way to get extensibility without forcing new interfaces is to use loose typing, which kind of negates many of the advantages of XML...

[#] Mon Dec 14 2009 09:44:07 EST from dothebart @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

 

Mo Dez 14 2009 08:54:12 EST von LoanShark @ Uncensored
well designed API can maintain compatibility for a very long time IF
the programmer has the incentive to do so.. AND IF THEY HAVE THE SKILL.


Except if the API under discussion is a SOAP API, in which case the answer is: there is no backwards compatibility without adding an entirely new interface, stop complaining and go away. Kind of sucks, actually: your only way to get extensibility without forcing new interfaces is to use loose typing, which kind of negates many of the advantages of XML...

Heh, I was about to sugest making all kernel apis talking xml ;-)



[#] Mon Dec 14 2009 13:13:46 EST from Ford II @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

I was astounded when I first saw soap.
It one fell swoop it manages to define a process for doing things in a somewhat cool fashion then overcomplicates the whole mess so that
forget about doing the cool part, doing anything no matter how trivial is impossible and requires 6 servers to be online to function at all.

The soap people should be shot for having the balls to put an "S" on the front of it.
Fucking assholes, all of them.

[#] Mon Dec 14 2009 13:14:07 EST from Ford II @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

Sorry, I'm not supposed to curse anymore. Fucking politicians.

[#] Mon Dec 14 2009 13:40:45 EST from IO ERROR @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

Wait until you see REST.

[#] Mon Dec 14 2009 15:38:56 EST from Ford II @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

I have I stopped looking.

I'm a big fan of "If you don't like what you see, don't look."

[#] Mon Dec 14 2009 16:02:03 EST from cellofellow @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

things to allow for future expansion without breaking compatibility, a
well designed API can maintain compatibility for a very long time IF
the programmer has the incentive to do so.. AND IF THEY HAVE THE SKILL.

So, which is it that the kernel team lacks, incentive or skill? (That's
not an xor.)

[#] Mon Dec 14 2009 16:11:48 EST from dothebart @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

 

Mo Dez 14 2009 13:40:45 EST von IO ERROR @ Uncensored
Wait until you see REST.

whats that wrong about REST? Its primary design goals are just to have a path based persistent url scheme, plus that it more cleanly defines when to use GET/POST/PUT... so the whole URL scheme makes a well defined sentence?

For shure you can also use soap on the transport layer, but usual mime encoded or json post is also fine.



[#] Mon Dec 14 2009 16:25:24 EST from Peter Pulse @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]


So, which is it that the kernel team lacks, incentive or skill? (That's

not an xor.)


Well, they definitely lack the incentive. I don't know about skill.

[#] Mon Dec 14 2009 22:25:32 EST from IGnatius T Foobar @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

I think they may just have a different order of priorities than most of us would like to see.

[#] Tue Dec 15 2009 16:13:32 EST from Ford II @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

So who's right? Theya re are. If you can write a competing kernel, by all means go ahead.

actually, here's a sinister thought.
Branch the kernel somewhere, and promise you'll keep the ABI stable.
Take all the patches from the main kernel line except for the ones that break the ABI.
I'm kinda wondering why somebody' hasn't done this already.
you'd have all the hardware vendors knocking at your door.

[#] Tue Dec 15 2009 17:24:50 EST from Peter Pulse @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

That thought has occurred to me. If a larger distro forked the kernel, eg ubuntu, and effectively solved the device driver problem for everybody.. then the debate would be over. The would probably only need to maintain the fork for a year or two.. and then it would get merged.

[#] Wed Dec 16 2009 11:13:58 EST from IGnatius T Foobar @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

Red Hat and Canonical together could probably wrest control of the kernel away from Linus for any reason, based on momentum alone. In fact, Linus said a long time ago that not only is this inevitable, but that he's ok with being succeeded when the community decides that it's time to move on.

[#] Wed Dec 16 2009 15:18:11 EST from Ford II @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

yeah, but when the moment comes...

Go to page: First ... 37 38 39 40 [41] 42 43 44 45 ... Last