For those familiar with Ziggy's work, he finally compiled a kernel for the Thunderbolt. It is a beta kernel so there will be bugs, so test it out. For reporting bugs please comment on his website. He is a great kernel dev. Please donate to him if you like his work. I am in no way affiliated with Ziggy, just wanted to spread the news.
UPDATE: My previous thread was closed because of a direct link I provided. I decided to create a new thread just for discussion purposes and bug tracking. You can google "ziggy471" to get to his site for the kernel. You can also google the name of the latest kernel update for the link.
Latest Kernel Update:
Beta Kernels 10 Apr 11
Running BFS kernel, and getting the best battery life I've ever experienced. HIGHLY HIGHLY HIGHLY RECOMMEND.
Last thread was closed because ziggy is not following GPL and is not posting his source, which is required. XDA cracks down hard on people who do not follow GPL.
nemesys504 said:
For those familiar with Ziggy's work, he finally compiled a kernel for the Thunderbolt. It is a beta kernel so there will be bugs, so test it out. For reporting bugs please comment on his website. He is a great kernel dev. Please donate to him if you like his work. I am in no way affiliated with Ziggy, just wanted to spread the news.
UPDATE: My previous thread was closed because of a direct link I provided. I decided to create a new thread just for discussion purposes and bug tracking. You can google "ziggy471" to get to his site for the kernel or use the pic attached for reference. You can also google the name of the latest kernel update for the link.
Latest Kernel Update:
Beta MECHA Kernel 6 Apr 11
Click to expand...
Click to collapse
You don't get it...
cabagekiller said:
Last thread was closed because ziggy is not following GPL and is not posting his source, which is required. XDA cracks down hard on people who do not follow GPL.
Click to expand...
Click to collapse
You are correct and I spoke to Ziggy on this issue and was told when his kernel is stable enough he will release his source.
adrynalyne said:
You don't get it...
Click to expand...
Click to collapse
Whether I get it or not, I think his kernel deserves a forum for discussion. Thank you for your 2 cents.
I agree, my battery life is amazingly good.
Sent from my ADR6400L using XDA Premium App
His new test ones are out.
ridobe said:
His new test ones are out.
Click to expand...
Click to collapse
Yeah and it comes with a script! lol
Anyone else's phone running super hot with the new kernel that was released today? Mine is just too hot to touch almost...thinking about going back to the kernel before this update if it doesn't change soon.
Thunderbolt Rooted!
andrew53517 said:
Yeah and it comes with a script! lol
Click to expand...
Click to collapse
I don't have access to a computer all the time (or very often). Is there a way to copy/paste that script into the init.d folder through Root Explorer (or another app) instead of having to push it with ADB? Thanks in advance for any help!
Edit: Nevermind I figured it out. Having random restarts with the Kernel though so I'm reverting back to the BFS 4-6-11 kernel. That one was rock solid and the only issue was the proximity sensor.
I have his 4-10 BFS, what are you suppose to do with the script and why?
Going by what Ziggy said on his blog, the script is used to lower voltages/save a lot of power. I didn't have good luck with the kernel/script combo or just the kernel itself. It ran super hot and I was getting random lockups and random reboots on even the stock clock frequency. I moved back to the 040611 BFS kernel since the only issue I had with that kernel was the proximity sensor. The 040611 kernel also had insanely good battery life (or at least for how I use the phone, it did).
LSUstang05 said:
Going by what Ziggy said on his blog, the script is used to lower voltages/save a lot of power. I didn't have good luck with the kernel/script combo or just the kernel itself. It ran super hot and I was getting random lockups and random reboots on even the stock clock frequency. I moved back to the 040611 BFS kernel since the only issue I had with that kernel was the proximity sensor. The 040611 kernel also had insanely good battery life (or at least for how I use the phone, it did).
Click to expand...
Click to collapse
+1. It locked up on me too and ran super super hot. Reverted back till fixed.
Thunderbolt Rooted!
nemesys504 said:
Whether I get it or not, I think his kernel deserves a forum for discussion.
Click to expand...
Click to collapse
+1
LSUstang05 said:
Going by what Ziggy said on his blog, the script is used to lower voltages/save a lot of power. I didn't have good luck with the kernel/script combo or just the kernel itself. It ran super hot and I was getting random lockups and random reboots on even the stock clock frequency. I moved back to the 040611 BFS kernel since the only issue I had with that kernel was the proximity sensor. The 040611 kernel also had insanely good battery life (or at least for how I use the phone, it did).
Click to expand...
Click to collapse
mine didn't lock up, but it was warm all the time (even when i wasn't using it) and had insane battery drain, like 40% in 2 hours. i reverted to 4-6-11 kernel and all is well again
edit: this is obvious to xda regulars, but noobs should download & flash the MECHA kernels for Tbolt. all other roms are for other devices. if you flash your new Tbolt with an EVO rom, you will be a very sad panda
Where is the source for this kernel?
jlevy73 said:
Where is the source for this kernel?
Click to expand...
Click to collapse
This has been asked several times, so I figured i would jump in and share what I know...
I speak to Ziggy almost daily when helping him debug stuff and he has spoken rather openly about this. He's not playing games or avoiding the issue and is going to post his sources and patches soon. There are one-and-a-half reasons he hasn't so far:
The half reason: There are some voltage issues and frankenstine tree problems that are causing some non-booters that need to be fixed before a public release can be considered safe. Now, the reason this is a "half reason" is because some may argue that he still needs to release it under GPL terms even though it's a beta, while others would argue that HTC doesn't release their betas under the GPL until they are safe either. If they did, HTC would have dropped their source 6 months ago, but they didn't. So it's an argument of where you stand semantics. I'm not telling you where to stand on that one - make up your own mind. However, it is worth noting that Ziggy himself never started a TB kernel thread SPECIFICALLY for the reason that he did not want to violate XDA's terms in accordance with the GPL. Other users started their own Ziggy threads independently
The bigger reason: He is currently in talks with an intellectual property attorney in order to retain personal IP rights on some of the code he has personally written, and was advised by that attorney to not release his full source under the GPL since that source would include the code he is trying to secure. Once that is taken care of, he will release the bulk of his source and patches, while retaining a few flashable patches for himself of his own personal code to further enhance the kernel - assuming he gets that all worked out with the IP lawyer.
That may frustrate some people, while making others very happy. I can also tell some of the devs are getting anxious since they see Ziggy added/changed/removed over 35,000 lines of code in the TB kernel and their eyebrows raise a little and they want his source so they can see what he's up to I don't know where you stand on the issue, nor will I tell you which side to take. I already have his source so quite frankly I don't care either. Again, I'm just the messenger sharing what I know. Don't hate on me if you don't like the info above - it's not my call
You'll all get the source/patches soon enough
i can't say i blame ziggy for doing things this way. it's his kernel, he has the right to do what he wants with it, including seeking intellectual rights. i'm glad he made his kernels available for the rest of us to try. more rom/kernel options is good for all of us
IANAL but sounds like walking a fine line...any of the witheld patches will be designed specifically for the purpose of merging with GPL licensed code. I'm sure the attorney knows his stuff, but at minimum doesn't seem in the spirit of AOSP.
eschelon said:
This has been asked several times, so I figured i would jump in and share what I know...
I speak to Ziggy almost daily when helping him debug stuff and he has spoken rather openly about this. He's not playing games or avoiding the issue and is going to post his sources and patches soon. There are one-and-a-half reasons he hasn't so far:
The half reason: There are some voltage issues and frankenstine tree problems that are causing some non-booters that need to be fixed before a public release can be considered safe. Now, the reason this is a "half reason" is because some may argue that he still needs to release it under GPL terms even though it's a beta, while others would argue that HTC doesn't release their betas under the GPL until they are safe either. If they did, HTC would have dropped their source 6 months ago, but they didn't. So it's an argument of where you stand semantics. I'm not telling you where to stand on that one - make up your own mind. However, it is worth noting that Ziggy himself never started a TB kernel thread SPECIFICALLY for the reason that he did not want to violate XDA's terms in accordance with the GPL. Other users started their own Ziggy threads independently
The bigger reason: He is currently in talks with an intellectual property attorney in order to retain personal IP rights on some of the code he has personally written, and was advised by that attorney to not release his full source under the GPL since that source would include the code he is trying to secure. Once that is taken care of, he will release the bulk of his source and patches, while retaining a few flashable patches for himself of his own personal code to further enhance the kernel - assuming he gets that all worked out with the IP lawyer.
That may frustrate some people, while making others very happy. I can also tell some of the devs are getting anxious since they see Ziggy added/changed/removed over 35,000 lines of code in the TB kernel and their eyebrows raise a little and they want his source so they can see what he's up to I don't know where you stand on the issue, nor will I tell you which side to take. I already have his source so quite frankly I don't care either. Again, I'm just the messenger sharing what I know. Don't hate on me if you don't like the info above - it's not my call
You'll all get the source/patches soon enough
Click to expand...
Click to collapse
I do appreciate the quite thorough explanation regarding the rationale of not releasing his kernel source. While GPL is a discussion for another day, the whole thing for me is by definition, Android is AOSP. I'm seeing a disturbing trend not amongst developers so much but from manufacturers re-writing the rules on being Open Source. Take Motorola for example. They release all phones with a hardware lock on their bootloaders. Poor folks using the Atrix have to go through a ridiculous side loader app to download anything not from the market. Perhaps Google should start a new branch called the Android Unopen Source Project
Anyway, I don't know all the specifics behind Ziggy's IP issues so not knowing the full extent of the facts I won't comment on that. I respect Ziggy and appreciate what he brings to Android. I just don't want to see developers close their source code because if Cyanogen took that some approach where do you think the development community would be today?
Post removed
Related
I'm just putting this in a new thread so that everyone can see it without having to accidentally come across it in the Hero Source Attempts thread... Some other users have realized that if everyone who has a twitter account messages HTC through twitter, it becomes bad PR for them because everyone sees it, and they are more likely to meet our demands at a speedier pace.
If you really want lots of cool ROMs and lots of options, we gotta get that dang kernel, and this seems to be the best tactic so far. Supposedly it worked in getting the GSM kernel. SO GET TO WORK PEOPLE! START TWEETING/Messaging THROUGH TWITTER @HTC!!
Here is the original post by another user:
I personally believe that these two methods would work fastest. If they get 1000 emails, no one hears about it. But if they get 1000 tweets, or an article on Engadget, it's bad PR. This is basically what happened with the GSM Hero:
slashdot article - tech.slashdot.org/story/09/10/16/1720224/HTC-Dragging-Feet-On-GPL-Source-Release-For-Hero-Phone
acknowledgement - twitter.com/htc/status/4928377685
compliance - twitter.com/htc/status/5071201112
admission of responsibility - twitter.com/htc/status/5071514606
(sorry, I've been a member for almost 3 years but this is my first post... can't post links)
I tweeted the following, please retweet or write your own similar: @htc When can we expect to see the CDMA (Sprint) Hero kernel source code? It's been 3 months, this is ridiculous! #gplviolation
I posted a tweet, lets hope this will push them to at least acknowledge the requests.
posted a tweet too hope it helps
Posted a Tweet, i pray engadet will pick up on this.
lol been posting at least 2 tweets a day for the last 3 days. glad to see others are joining in.
Yup. Tweeted
@HTC come on, it's long past the weekend.CDMA Hero sources please.#HTC get your act together #GPL #Violation #CDMA #Hero #Sources
Click to expand...
Click to collapse
to try and get as many tags in as possible...
EDIT: Well, a search for #gplviolation on twitter is certainly interesting! (Try it...)
if you search htc you get a lot of people asking how to update to 2.x reply tweeet them to get the word out if you can.
Done! I hope we see something soon.
Done! Tweeting twice a day.
If you post a tweet regarding this, please be sure to include @htc, @sprint, and add the #gplviolation hashtag for tracking purposes.
tweet sent!
Does it really matter much if we get the kernel? As I understand it, there's a load of closed-source proprietary software running under the hood on our devices.
It depends. If HTC compiled proprietary code into the kernel itself, they're between a rock and a hard spot. Under the GPL, anything physically compiled into the kernel MUST have its source released. If HTC licensed proprietary camera drivers from anyone (Qualcomm, most likely) under terms that forbid them from disclosing the source, it's *their* problem to worry about.
IMHO, if that's the situation HTC is in, the best thing they could do to at least get everyone off their back would be to just go ahead and release their best 2.1 internal build (officially, for testing with the Android Emulator, since they can't officially condone rooting) as a "developer's preview". If they did, the necessary files would be ripped and built into a working 2.1 heroc distro within days, if not hours, and pretty much everyone would forget about the source for now & give them some breathing room for a few months.
As I understand it, even if HTC's 2.6.29 kernel had bugs, as long as those bugs weren't with msm_camera itself, we could use THAT 2.6.29 kernel to bootstrap newer builds of 2.6.29 (kind of like how Microsoft used prerelease versions of Visual Studio 2010 and Windows 7 to build Windows 7 itself). The problem now is that there's a literal hole in the 2.6.29 kernel that we can't fill, because we have neither the include file's source nor a compiled binary to drop in place.
Now, it's important to remember that we can't actually demand the 2.1 kernel yet under the GPL, since it hasn't actually been released yet. I'm only mentioning that as an *alternative* that would satisfy pretty much everyone for now, to give HTC some constructive alternatives to consider if releasing the full 1.5 kernel source for heroc is, in fact, completely out of the question due to licensing problems arising from msm_camera. Regardless of whether or not HTC can release the source to msm_camera for heroc, they can obviously redistribute 2.6.29 binaries built from it... and one of those binaries would be more than adequate for our purposes right now.
miamicanes said:
, it's important to remember that we can't actually demand the 2.1 kernel yet under the GPL, since it hasn't actually been released yet.
Click to expand...
Click to collapse
I realize you are referring to a CDMA-specific kernel (I thought 2.0 and after would be GSM and CDMA ready?), but the kernel for 2.1 HAS been commercially released. It's running on the Nexus One. Demanding the code under GPL is perfectly reasonable.
I mention this because this problem is now beyond any specific device. The manufacturers and carriers are, in my opinion, abusing the GPL and we ought to have a united front on that fact.
5tr4t4 said:
I realize you are referring to a CDMA-specific kernel (I thought 2.0 and after would be GSM and CDMA ready?), but the kernel for 2.1 HAS been commercially released. It's running on the Nexus One. Demanding the code under GPL is perfectly reasonable.
I mention this because this problem is now beyond any specific device. The manufacturers and carriers are, in my opinion, abusing the GPL and we ought to have a united front on that fact.
Click to expand...
Click to collapse
The source for the kernel compiled for the Nexus One, which uses completely different hardware, is (or must be) available. HTC does not need to provide it, as they are not the company selling the device - Google is.
^^^ Just to add to what he said, the kernel for the Nexus One also lacks the compiled-in driver for the CDMA Hero's camera.
Here's an example to illustrate why the GPL places so much practical importance upon the availability of ALL source used to build the kernel... and why it's generally accepted that proprietary binary kernel loadable modules are OK (at least, among pragmatists like Linus). Suppose the maker of your PC used a proprietary NVIDIA chipset with no public documentation, and shipped it with Ubuntu Linux on the hard drive. However, suppose they compiled the video driver directly into the kernel.
Anyone who bought the computer would be put in a needlessly bad position -- unless someone reverse-engineered the chipset, you wouldn't be able to use any distro of Linux not officially blessed and released by the computer's maker. You might be able to use a slightly newer build of Ubuntu if someone did a binary diff on the newer kernel and pulled out the metaphorical duct tape. You might possiblybe able to get away with using the old kernel in a newer distro (enjoying some bugfixes in the other programs besides the kernel itself). You might even be able to diff a newer build of Linux on a newer, but similar, computer released by that maker that they happened to ship with a newer kernel. But you'd never really be able to build your own kernel the way God and Linus intended, because the kernel and proprietary video driver would be inseparable. If you tried, the compiler would complain because it was missing a very, very important #include file -- the proprietary video driver.
On the other hand, suppose the manufacturer bundled the proprietary video driver as a loadable kernel module (.ko file). NOW, things change significantly. Richard Stallman might still grouse because you don't have the source to the video driver, but in utilitarian terms, you're much better off than you were in scenario #1. Although you're still dependent upon the manufacturer for a newer video driver, because it's physically separate from the kernel itself, you can build your own newer, better, and different kernels whenever and however you'd like. As long as the low-level interface between the kernel itself and the kernel module doesn't change on your platform, the two are sufficiently abstracted from each other to allow one to change without affecting the other.
IMHO, the most disgraceful part of this whole thing is that we theoretically have phones running an open platform, but we're still reduced to ripping binary images and tacking them together with metaphorical duct tape, just like we were with Windows Mobile. If anything, it's gotten worse. At least Windows Mobile didn't have to be rooted, and the newer versions generally didn't break the previous version's device drivers. Sigh.
miamicanes said:
^^^ Just to add to what he said, the kernel for the Nexus One also lacks the compiled-in driver for the CDMA Hero's camera.
Click to expand...
Click to collapse
Right, I understand this. I was making the point that the fact that 2.1 has a commercial release means the we can demand the code under GPL. Shouldn't we be aiming for a unified android kernel source with GSM and CDMA support, adding binary drivers/libs (or setting device-specific compile flags) as needed? Nexus being controlled by Google (who seems to be releasing their modifications immediately on git) might be a starting place for this de facto Android.
I'm simply advocating for thinking beyond our own personal devices.
Holy shut!!! Welcome to the age of technology.... **** with us and we will tweet Ur ass to death. Lol. It's an all Twitter offensive. Were declaring Twitter war on HTC until we get source. ROFL
@5tr4t4: well, it was more for the benefit of others who might stumble on this thread and aren't quite sure why it's such a big deal
I think what Jonnythan was saying is that there's no need to get the source to the Nexus One's kernel from HTC, because you can download it right now directly from Google.
As far as platform neutrality goes, we'd be 99.9% of the way there if HTC would just move the proprietary stuff out of the kernel proper and into loadable kernel modules so they'd simultaneously be in compliance with the GPL and not making our lives needlessly difficult by making us jump over hurdles that shouldn't be blocking our way in the first place
miamicanes said:
As far as platform neutrality goes, we'd be 99.9% of the way there if HTC would just move the proprietary stuff out of the kernel proper and into loadable kernel modules so they'd simultaneously be in compliance with the GPL and not making our lives needlessly difficult by making us jump over hurdles that shouldn't be blocking our way in the first place
Click to expand...
Click to collapse
If they were to move some stuff to binary *.ko's they'd most likely move all non-boot-essential hardware support out there, which would actually make things much, much more challenging for us. That way they could have a "universal" kernel (and GPL source tree) that is used across devices, and each device just has its own *.ko's. They'd only have to release one (fairly useless) tarball for GPL compliance. Be careful what you ask for.
We need to bomb HTC's website with comments to encourage them to release the kernel source code for our device. I suggest we all go to the following link daily and request its release;
http://htcdev.com/contact
HTC just sent me a link to take a survey, another good tool to blast them with.
http://survey.htc.com/worldwide
Code has been released, I like to think all our complaints helped. Feel free to lock this thread if need be!
http://www.htcdev.com/devcenter/downloads
We have been. I've sent them several notices on a near daily basis.
Sent from my myTouch_4G_Slide using xda premium
I doubt that that link is anything more than a placebo.
http://www.htc.com/us/about/contact-by-email
Say something along the lines of "you're in violation of GPLv2 which requires that source be released along with binary. GPLv2 does not allow for anything besides release of source NOT being ANY LATER than binary distribution."
I.e., though GPLv2 doesn't specify an exact time frame, the implication of this is that the source must be made available by the EXACT MOMENT that the binary is distributed. It *does* allow for the source to be released BEFORE the binary, but does NOT allow for the binary to be released before the source.
IMO, the kernel source archive should be included within the system partition of the phone, at least for early releases while there is sufficient storage space for it all to fit. This would greatly simply source distribution.
Even though I went to that page and asked for the kernel source code to be released, it looks like they're on a pretty routine schedule as far as what and when they release things and we're probably still a little ways out on the source code. But it can't HURT to keep trying, right?
Submitted. Hopefully they'll listen up.
BiggJurk said:
We need to bomb HTC's website with comments to encourage them to release the kernel source code for our device. I suggest we all go to the following link daily and request its release;
http://htcdev.com/contact
Click to expand...
Click to collapse
Yeah, we have been. As unclespoon said they are on a fairly set release schedule that they must be comfortable with [legal-wise].
Read my replies here, there is another link that got me a response that was from a human:
http://forum.xda-developers.com/showthread.php?t=1247374
HTC does this **** on purpose. They have a bunch of new devices coming out and if they were to release the code that would impact there profit margins. This processor can handle 1.5 ghz as a daily driver. The new HTC amaze has exact same processor but is overclocked 300mhz more then our device. And it has a 1gb of RAM. Samsung has gotten great at releasing there code within 1 week or even earlier. HTC PLEASE TAKE NOTES FROM SAMSUNG.
Sent from my myTouch_4G_Slide using xda premium
FYI
I filled out a customer service survey from HTC and gave them all bad ratings in regards to their non-response for the kernel source code. A representative just personally called me and is trying to get an eta on the release if not email me a copy of the code. I would suggest everyone completes a survey with negative comments at the following location:http://survey.htc.com/worldwide. I know surveys like this affects their metrics and gets managements attention. The guy on the phone also said that Android is released under the Apache license agreement.
Regards,
Filled out the survey.
Let's see if they respond.
cal3thousand said:
Filled out the survey.
Let's see if they respond.
Click to expand...
Click to collapse
I think it took them 2 weeks to get back to me.
BiggJurk said:
I think it took them 2 weeks to get back to me.
Click to expand...
Click to collapse
My guess is that they'll "get back to you" in a month or however long until they would have normally released the source code. I think they're too big to be bothered by people complaining about lack of source code. Bottom line is there probably won't ever be any "consequences" as a result of them taking their time on releasing kernel source. We only complain because we want it, but it's not like they are really doing anything wrong by just releasing it on their own schedule.
BiggJurk said:
The guy on the phone also said that Android is released under the Apache license agreement.
Click to expand...
Click to collapse
I've heard that before, but I don't see how that's possible since Android is based on Linux. If it were based on BSD that'd be another matter.
BiggJurk said:
The guy on the phone also said that Android is released under the Apache license agreement.
Click to expand...
Click to collapse
Wow, congrats to phone guy!! Unfortunately, either he was trying to get you to shut-up or misunderstood what you wanted them to release. Google mostly licensed Android with the Apache 2.0. This allows others to customize Android and they don't have to release their changes i.e. customizations made by phone manufacturers (it means other things too but this was Google's main reason for this license). HTC doesn't have to give us their Android source. The Linux kernel is GPL - there is no way around that. The GPL states that the source must be released at the same time as the binary is released to the end-user (it even states that the source should be no harder to obtain than the binary is i.e. we should get the kernel source with our devices - on the sd card or something). Still have no idea where HTC gets 90-120 days from the GPL wording.
I sent a note to EFF asking if they were aware of whats going on. They said they were and were researching the situation.
---------- Post added at 06:50 PM ---------- Previous post was at 06:37 PM ----------
unclespoon said:
but it's not like they are really doing anything wrong by just releasing it on their own schedule.
Click to expand...
Click to collapse
They are though. They are directly violating the GNU GPL but you are right - there are too few of us who actually want the kernel source for them to really worry. Can't believe one of the actual Linux kernel devs hasn't caught wind of this and made a statement.
I sent a couple of requests. Let's hope they move their asses.
Source has been released:
http://www.htcdev.com/devcenter/downloads
HebrewToYou said:
Source has been released:
http://www.htcdev.com/devcenter/downloads
Click to expand...
Click to collapse
I think you were the first one to find it. I thanked you elsewhere you've mentioned it as well.
Maybe the OP can come through and update the thread title.
Edit to add - download reads 94.0MB on the HTC page, but my download over Tmo 4g is saying out of 89.6MB and my home pc is saying 89.7MB...so we'll see what's up when I get it.
YES!!! Time to OC this bad boy..
Please get on it Devs..!!!
RazoE said:
YES!!! Time to OC this bad boy..
Please get on it Devs..!!!
Click to expand...
Click to collapse
All ready on it
Sent from my Senseless Doubleshot using xda premium
That's funny.
I just received the HTC reply to my request. I'm going to play like my request was the straw for that camel's back... Your Welcome Everybody!!!
j/k. This is wonderful news though. I'm stoked
Thread locked by OP request
There are several kernel tweaks implemented by various devs that require/support adjustment of some sort of parameters. As an interface a dev usually adds some additional entries to the sysfs. When writing a GUI/frontend for this sysfs interface one simply reads/writes a value from/to these sysfs entries.
Around a year ago one CM team dev (which shall remained unnamed) did start to take kernel tweaks that are out there from other independent kernel devs and to re-implement them under an incompatible interface. His goal was to unify the sysfs interface across different devices so when implementing a GUI in the CM ROM Control the CM devs could use the same sysfs hook. This meant less work for the CM devs since they could use the same code in the ROM across different devices without modification.
However on the other hand that also meant that for each of those devices there now were two incompatible implementations for the same functionality which in most cases could not be both simultaneously added to the kernel. And while some kernel devs stuck to the original implementation, others adopted the CM version to be compatible with the CM ROM Controls. So this practice of CM did lead to an additional artificial fragmentation for those devices resulting in several negative consequences for both independent kernel devs and also the common users.
For kernel devs this means that they are forced to make a decision which implementation to support which practically means to decide which GUI tools to break since these are normally only compatible to one implementation. The original kernel dev of these ripped-off tweaks are hit the hardest since some of them have put out apps on the market to fund their work. So when other kernel devs adapt the CM flavor their apps will no longer work with these kernels.
On the other hand there is the common user which now has the additional problem to keep track which flavor is implemented in the kernel he is using and which GUI tools work with it. This results in unnecessary confusion which again leads to people complaining to the kernel devs that this or that GUI tool/ROM Control is not working.
As one can see the decisions CM has made work out fine for CM themself, however independent kernel devs and essentially the entire community gets the short end of the stick.
In February I contacted that one CM dev who was reponsible for these incompatible re-implementations and I explained my point of view, however he was not willing to cooperate. So early March Imoseyon, Francisco, Morfic and me contacted the CM team leaders. The reponse from the CM team was friendly, they seemed to be willing to cooperate and promises were made to get this problem resolved. Unfortunately it became clear that these promises were not sincere since after giving us a run-around for two entire month nothing at all has happened (http://h11.abload.de/img/cm11t89f.jpg).
At the end of these two month of fooling around with us and wasting our time the CM team did inform us that not only they will not revert the changes they made to fix the mess and confusion they caused but also that for the future they reserve the right to take kernel tweaks from other independent devs out there and re-implement them under incompatible interfaces (http://h11.abload.de/img/cm2evk65.jpg).
For kernel devs in practise this means that one cannot release a new tweak without fearing that CM takes it and reimplements it under an incompatible interface creating another mess. So for the future if one wants to implement a new functionality one better makes sure to use the same sysfs interface that CM has defined at standard. Whether this is intended or not by CM, this will be the practical end result. And having that threat always lingering in the background when one releases a new tweak is simply not acceptable.
We tried to avoid the drama that comes with publicly critizing other developers and showed a lot of restraint and patience in working out a compromise with the CM team in private, however as anyone can see from the published communications our effort clearly have reached a dead end.
We strongly feel that this is an important issue not only for us but also other independent kernel devs and the entire community and we thus feel responsible to bring an end to this hurtful practise adopted by the CM team of creating additional unneccessary fragmentation. So we turn to you - the community - to ask you to voice your concerns to the CM team. Please contact Jef Oliver ([email protected]) and let him know what you think - as always be respectful.
seriously didn't know the CM team owed you anything. They can do whatever the hell they want. Its your choice what you want to support or not.
I'm sympathetic to your situation, and I understand the frustration that must cause you as a developer. As and end-user no one wants a situation where there are multiple GUI tools that are incompatible. You shouldn't use terms like "ripped-off" though as it implies theft. This is GPL code, as long as the cyanogenmod team are releasing their code and changes back to the community they aren't doing anything wrong (annoying maybe).
codf4ther said:
I'm sympathetic to your situation, and I understand the frustration that must cause you as a developer. As and end-user no one wants a situation where there are multiple GUI tools that are incompatible. You shouldn't use terms like "ripped-off" though as it implies theft. This is GPL code, as long as the cyanogenmod team are releasing their code and changes back to the community they aren't doing anything wrong (annoying maybe).
Click to expand...
Click to collapse
Well CM team aren't doing anything illegal, but what they are doing is just wrong. Taking a dev's work and turning it into their own work without permission and cease support on the original work. That's plain wrong...
Sent from my Nexus S using Tapatalk 2
Why not adopt CM's sysfs interface as a standard? Then either the kernel apps or rom control can both control the kernel? Isn't that best for the community?
I remember when we never had to pay to control our kernel, now you are basically forced to buy the kernel apps ... Doesn't forcing users to buy separate apps actually hurt the community and foss?
I have no problem with supporting the great work of rom or kernel developers but, I would rather donate to a dev than be forced into a market app to control the kernel.
I have bought Franco, GLaDOS and Trinity apps btw.
ljordan2 said:
Well CM team aren't doing anything illegal, but what they are doing is just wrong. Taking a dev's work and turning it into their own work without permission and cease support on the original work. That's plain wrong...
Sent from my Nexus S using Tapatalk 2
Click to expand...
Click to collapse
ummm this wasnt about permission, furthermore the code is gpl, dont need permission as long as they obey the licence and release source. the case here is fragmentation caused.
codf4ther said:
I'm sympathetic to your situation, and I understand the frustration that must cause you as a developer. As and end-user no one wants a situation where there are multiple GUI tools that are incompatible. You shouldn't use terms like "ripped-off" though as it implies theft. This is GPL code, as long as the cyanogenmod team are releasing their code and changes back to the community they aren't doing anything wrong (annoying maybe).
Click to expand...
Click to collapse
I never said they stole something nor that they did something illegal. I am just describing the consequences of their decisions which is hurting independent devs and the community for the sake of saving some work for the CM team devs. And hurting others out of laziness is wrong in my book.
I remember the different Voodoo and BLN sysfs in NS CM
and Color Control for GN
The Kernels using Ezekeel's Color Control
GLaDOS / franco / Trinity / Lean / Popcorn / Air
vs
The Kernels using CM's Color Control
CM / CMPlus / faux123 / JameBond / FuguMod
serious disruption!
blowtorch said:
Why not adopt CM's sysfs interface as a standard? Then either the kernel apps or rom control can both control the kernel? Isn't that best for the community?
I remember when we never had to pay to control our kernel, now you are basically forced to buy the kernel apps ... Doesn't forcing users to buy separate apps actually hurt the community and foss?
I have no problem with supporting the great work of rom or kernel developers but, I would rather donate to a dev than be forced into a market app to control the kernel.
I have bought Franco, GLaDOS and Trinity apps btw.
Click to expand...
Click to collapse
+1 Sounds like a format war to me. If there's no disadvantages to their implementation than I don't see what the big deal is.
JS0724 said:
+1 Sounds like a format war to me. If there's no disadvantages to their implementation than I don't see what the big deal is.
Click to expand...
Click to collapse
All users across all devices would benefit from using CM's kernel standard
Come on, guys
If CM team set their sysfs, the original dev should modify his own?
blowtorch said:
All users across all devices would benefit from using CM's kernel standard
Click to expand...
Click to collapse
Read the post again please.
nexus.prime said:
Come on, guys
If CM team set their sysfs, the original dev should modify his own?
Click to expand...
Click to collapse
They doesnt have to modify. Only if they want to merge things into CM. You cannot suppose that CM has to change their standards to adapt to other devs.
Its like Samsung asking AOSP to change their code standards to adapt to Touchwiz.
I'm not sure what to say about this but it's reminiscent of the Ultimate Droid drama. It does sound like that they do not want anyone 'in their way'.
CM roms have always been about do things their way. It is not a surprise if they decided to do it their way. They only support their coding. If you don't like something in their kernel then its simple. Don't use it as a base and build your kernel and rom from the AOSP source code.
Sent from my Inspire 4G using Tapatalk 2
According to what the OP stated, if this is true, then CM is no better than Microsoft, Apple or any other "evil" empire (Samsung?) that tries to lock down code for their own purposes while "borrowing" the work of others.
This is the opposite of Open Source mentality, they are creating a new "proprietary" standard. Similar in ways to what Samsung is doing with Tizen. Google it.
We does not live in a world where the strong prey upon the weak.
Android is people's OS!
ingenious247 said:
According to what the OP stated, if this is true, then CM is no better than Microsoft, Apple or any other "evil" empire (Samsung?) that tries to lock down code for their own purposes while "borrowing" the work of others.
This is the opposite of Open Source mentality, they are creating a new "proprietary" standard. Similar in ways to what Samsung is doing with Tizen. Google it.
Click to expand...
Click to collapse
Do note that these changes were opensource. Interfaces were open, and this was done to work for hundreds of devices for millions of users (Yeah.. CM is that big.).
Also, if these re-implementations were not limitations of the original work, why not adapt? Code that works for hundreds of devices are surly better than code working for just one? No?
blowtorch said:
All users across all devices would benefit from using CM's kernel standard
Click to expand...
Click to collapse
That's not how it work. To explain simply : Dev make some work in their kernel. CM team see it's usefull and worth to use it and take your work, adapt it to their "Standard" and add it to their kernel. Now you have two implementation for the same thing. Now, either the Dev has to make is whole code again to fit CM or leave it like this.
Now this tell us that it's not because the dev work against CM "standard", it's because CM changed is work and community "ask" them to use the CM way saying it's how it should have been done first. There is definitively something wrong here.
espenfjo said:
Do note that these changes were opensource. Interfaces were open, and this was done to work for hundreds of devices for millions of users (Yeah.. CM is that big.).
Also, if these re-implementations were not limitations of the original work, why not adapt? Code that works for hundreds of devices are surly better than code working for just one? No?
Click to expand...
Click to collapse
that's what i'm sayin
OK HTC ITS BEEN 90 DAYS, YOU KEEP SAYING YOUR SORRY FOR A CRAPPY PHONE HOW ABOUT YOU REDEEM YOURSELVES AND RELEASE THE DAMN SOURCE CODE NOW?
im just saying....
Patience. They can't release until its been 90 days since ota. Now that it has been 90 days they can but it doesn't mean they will. They can wait however long they desire. All I know is were getting closer.
Sent from my HTC Thunderbolt
ang1dust said:
OK HTC ITS BEEN 90 DAYS, YOU KEEP SAYING YOUR SORRY FOR A CRAPPY PHONE HOW ABOUT YOU REDEEM YOURSELVES AND RELEASE THE DAMN SOURCE CODE NOW?
im just saying....
Click to expand...
Click to collapse
It will be OK there Catwoman.
Sent from my Infected HTC Rezound using Tapatalk 4 Beta
Its 90-120 days people.....
Sent from my ADR6400L using Tapatalk 2
disconnecktie said:
Its 90-120 days people.....
Sent from my ADR6400L using Tapatalk 2
Click to expand...
Click to collapse
They have 45 more days. They will drop the source. But when the update went out they said 45 days to complete. Add that to the 90 by law.
Sent from my ConD3m3dPaC-man ADR6425LVW using xda app-developers app
People, there is no 90-day "rule". Why do people keep repeating this like it's a fact ?
hallstevenson said:
People, there is no 90-day "rule". Why do people keep repeating this like it's a fact ?
Click to expand...
Click to collapse
I think the point is HTC is trying to position themselves as "developer friendly". I'm not sure what the rules are, but it seems pretty unfriendly for them to withhold the code for this long. If they want to be seen as developer friendly, let them start releasing code for all devices at the same time as the OTA, or at least within a couple weeks. I can see them pointing fingers at Verizon for months of delay on the OTA, but delaying the release of the source code is on HTC. It just seems mean spirited as well.
If HTC really wants to indicate they are sorry for how Thunderbolt issues have been handled, they should release the source code.
hallstevenson said:
People, there is no 90-day "rule". Why do people keep repeating this like it's a fact ?
Click to expand...
Click to collapse
HTC is the one that stated that they can wait anywhere for 90-120 days to release their source code to ensure it is of the utmost quality. So all this repetition of it is merely because they made that statement. In response to the other quote about them about adding another 45 days because of the second update. I don't think that they will reset since the second update didn't do anything to the kernel at all.
Sent from my ADR6400L using Tapatalk 2
disconnecktie said:
HTC is the one that stated that they can wait anywhere for 90-120 days to release their source code to ensure it is of the utmost quality.
Click to expand...
Click to collapse
They clearly don't give a sh*t about the GPL as it doesn't allow 90 days or 120 days and that's all that really matters. When they say they can wait any period of time, they're effectively telling people "we'll do it if we feel like it".
Source will be available when HTC decides to publish it. Counting down the supposed days until release won't accomplish anything, nor will creating threads like this one and beating the topic to death. If one wants source, he or she would be better served by harassing HTC on Twitter, Facebook, Reddit, etc... Source will eventually be released though, that is certain...
Go to the link in this thread and ask them directly.
http://www.forums.infectedrom.com/showthread.php?p=74402
Sent from my ADR6400L using Tapatalk 2
There is no 90 day rule. The GPL requires release of source at the same time the binary is distributed, no ifs, ands, buts.
One of these days, a kernel developer (i.e. someone who holds copyright on part of the kernel) is going to sue them, win, and they will never be able to use the kernel again, per the terms of the GPL. HTC is playing with fire, since a significant part of their business requires use of the Linux kernel.
"You may not copy, modify, sublicense, or distribute the Program except as expressly provided under this License. Any attempt otherwise to copy, modify, sublicense or distribute the Program is void, and will automatically terminate your rights under this License. "
The GPL provides NO mechanism to regain those lost rights.
The kernel for the thunderbolt contains proprietary information that relates to the svdo technology therefore they can wait.
Sent from my ADR6400L using Tapatalk 2
disconnecktie said:
The kernel for the thunderbolt contains proprietary information that relates to the svdo technology therefore they can wait.
Click to expand...
Click to collapse
No, they can't. You obviously haven't read, or don't understand, GPL2. If they modified the kernel, or linked to it for "the svdo technology," they still have to release it, and that code is not proprietary, but also falls under GPL2.
"when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it."
Some light GPL reading and an explanation about the "free" parts of Android and the "non-free" parts.
Check it out!
Excerpt from the article:
Important firmware or drivers are generally proprietary also. These handle the phone network radio, WiFi, bluetooth, GPS, 3D graphics, the camera, the speaker, and in some cases the microphone too.
On some models, a few of these drivers are free, and there are some that you can do without—but you can't do without the microphone or the phone network radio.
Click to expand...
Click to collapse
mike.s said:
No, they can't. You obviously haven't read, or don't understand, GPL2. If they modified the kernel, or linked to it for "the svdo technology," they still have to release it, and that code is not proprietary, but also falls under GPL2.
"when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it."
Click to expand...
Click to collapse
The code related to svdo is a non free part. You will notice that the rezound also suffers from the same waiting period as the bolt since it to has svdo.
Sent from my ADR6400L using Tapatalk 2
disconnecktie said:
The code related to svdo is a non free part. You will notice that the rezound also suffers from the same waiting period as the bolt since it to has svdo.
Click to expand...
Click to collapse
So what? It may make a difference to what developers are able to do with it (e.g. kernel without the proprietaries doesn't allow a working system to be created), but it doesn't in any way remove their obligation to release the kernel source at the same time they release the kernel binary.
And, I'll admit I don't know how the kernel and the svdo stuff interact. But basically, if it's linked to the kernel (vs. working in userspace), then it's not non-free, as it is required to be released under GPL.
mike.s said:
So what? It may make a difference to what developers are able to do with it (e.g. kernel without the proprietaries doesn't allow a working system to be created), but it doesn't in any way remove their obligation to release the kernel source at the same time they release the kernel binary.
And, I'll admit I don't know how the kernel and the svdo stuff interact. But basically, if it's linked to the kernel (vs. working in userspace), then it's not non-free, as it is required to be released under GPL.
Click to expand...
Click to collapse
Sue them then and quit *****ing because they wait 90 days to release source code. Since you obviously know more about the gpl than those of us who work with the stuff then you should even take the lead and make the case for the rest of us. Radio technology is in the kernel or else the antennas wouldn't work. Since this device has svdo technology that is proprietary to Verizon and HTC then yea I would have to say that is a non free license. At any rate go file complaints with HTC and the gpl. It has already been don and it won't do you any good. Have fun with that.
Sent from my ADR6400L using Tapatalk 2
disconnecktie said:
Sue them then and quit *****ing because they wait 90 days to release source code. Since you obviously know more about the gpl than those of us who work with the stuff then you should even take the lead and make the case for the rest of us. Radio technology is in the kernel or else the antennas wouldn't work. Since this device has svdo technology that is proprietary to Verizon and HTC then yea I would have to say that is a non free license. At any rate go file complaints with HTC and the gpl. It has already been don and it won't do you any good. Have fun with that.
Click to expand...
Click to collapse
For someone who works with "the stuff," you're pretty clueless as to how it works. Maybe you should lay off "the stuff" for a while.
mike.s said:
For someone who works with "the stuff," you're pretty clueless as to how it works. Maybe you should lay off "the stuff" for a while.
Click to expand...
Click to collapse
Whatever you say chief. I'm guessing you've compiled some kernels and looked through kernel source. I guess we should take your lead and just whine about it the same thing that has plagued the bolt since day one some more just like you seem to do. Quit worrying about the day that kernel source drops and let those that are actually going to do something with the source do the worrying. You clearly don't understand that there is proprietary code in the thunderbolt source code which allows HTC to take their time with the release. I suppose you know that since you are so well versed in kernel source code though....
Sent from my ADR6400L using Tapatalk 2
In theory this should be quite useful, no?
Just putting this up here for those who may have lost hope, but on a whim I checked their source repository today and it would seem they've at least uploaded Kernel source!
ftp://Kernel_End_User:[email protected]/
Directory: Pure XL P0010UU (it's a bit of a mess, you may wish to CNTRL+F this)
I haven't checked their software repo yet for ROM source, but it was not uploaded when I initially found this information about a month and a half ago.
The kernel is only VANILLA STOCK source, I haven't compiled it or anything, I'm only linking their servers because I imagine that this isn't getting checked on a regular basis (not much to expect would happen). But, something has happened, so I figured I'd draw some attention to it.
Many thanks to those ROM and kernel devs who have been working to bring us some solid software. It's honestly my only major gripe with the phone.
We (me, acheron, root-expert) tried to compile this several times with CyanogenMod repos with no luck. It's from 7th December 2015 so nothing changed.
bemolx said:
We (me, acheron, root-expert) tried to compile this several times with CyanogenMod repos with no luck. It's from 7th December 2015 so nothing changed.
Click to expand...
Click to collapse
Darn. If only they were more willing to facilitate development.... the software is my only real issue with the phone. Thanks for your work, however.
Same thing here... I would love to have the latest CyanogenMod
Only for updating this post:
Kernel source, mostly ready for Marshmallow ROMs, you can find here on 'cm-13.0' branch.
Linux upstream 3.10.103
Still trying to boot it up.
Gonna update CyanogenMod thread soon.
Cheers
bemolx said:
Only for updating this post:
Kernel source, mostly ready for Marshmallow ROMs, you can find here on 'cm-13.0' branch.
Linux upstream 3.10.103
Still trying to boot it up.
Gonna update CyanogenMod thread soon.
Cheers
Click to expand...
Click to collapse
Great news @bemolx
TheLastCanadian said:
Darn. If only they were more willing to facilitate development.... the software is my only real issue with the phone. Thanks for your work, however.
Click to expand...
Click to collapse
Out of curiosity, how have other manufacturers "facilitated" this sort of development for their products?
vicks1008 said:
Out of curiosity, how have other manufacturers "facilitated" this sort of development for their products?
Click to expand...
Click to collapse
Some lend active support to the venture, LG has a dedicated team for liason, better documentation, etc.
I think it's probably pretty telling that it's only now the BLU source has worked - and it took them 5 months to even release it.
BLU releases kernel source codes upon request instead of proactively providing them. If they're asked for on launch, then the kernel source is released shortly after. So I don't believe the claim that it took 5 months to release.
Can you show me proof of other manufacturers lending support to show BLU?
NVMD.
TheLastCanadian said:
Your belief is irrelevant. They have had many requests, and always it is a referral to the FTP site they host. This site did not populate with the kernel/rom source for quite a few months after I bought the phone, and I was already behind the curve by about 2. I purchased mine on the 30th of December, 2015. I made this post the day after I noticed they had Kernel/Rom. If the URL was still working, I could verify for you the time limit. With that said, it was approximately 5 months.
As for other manufacturers lending support.... ZTE for instance is collaborating with Cyanogenmod, LG proactively provides source and has actually tried to make the process quite simple for most of their phones, and ultimately, contacting BLU about the matter is functionally worthless, as BLU is a reseller and at the whim of Gionee. BLU can't help because they don't do R&D or software as I can tell for the phone.
I'm particularly pissed about the fact I asked before I bought the phone if source was available and it was GPL compliant and I was told yes. 5 months is just a little outside of Amazon's return policy. The Pure XL is a good phone, but the software is quite lacklustre. CM would really be the bees' knees.
Click to expand...
Click to collapse
Well I'm obviously not going to bother contacting my connections at BLU with that attitude. Good luck guys!
vicks1008 said:
Well I'm obviously not going to bother contacting my connections at BLU with that attitude. Good luck guys!
Click to expand...
Click to collapse
I should correct myself slightly. Supposing my e-mail record is correct, they released it 4 months after the phone. I say your belief isn't relevant because a fact is a fact.... as of April 5th, I was still getting apologies from them about Kernel source not being available, specifically, "No ETA on source at this time". Ergo, it could have been longer.
As for BLU, I'm just being honest. They don't develop, they're a reseller.
bemolx said:
Only for updating this post:
Kernel source, mostly ready for Marshmallow ROMs, you can find here on 'cm-13.0' branch.
Linux upstream 3.10.103
Still trying to boot it up.
Gonna update CyanogenMod thread soon.
Cheers
Click to expand...
Click to collapse
Just a small update;
Linux kernel upstream: 3.10.104
Regenerated defconfig as well, the same branch.
I'll try it with full build today.