To late to test for the offical R14.0.0 release, but better late than never (R14.0.1). Some Trinity (TDE 3.5.13.x) quirks noted in a January 2014 review by Dedoimedo:
http://netrunner-mag.com/they-called-it-trinity/
* Difficulty installing from repositories.
* The default icon theme felt outdated.
* No network manager tool was available in the default desktop.
* Embedded webcam did not work.
* Zerconf did not work because avahi was not installed.
His conclusion:
"TDE must be a completely simple and smooth framework, otherwise it stands no chance against the competition. This is the prerequisite, even before you start thinking about discussing the pros and cons of its layout, use and whatnot. It must be as trivial as all others."
My notes:
He used a Live CD and thus, some of the quirks would be caused by the person making the iso rather than with upstream TDE.
While I have been a long-time Slackware user, nowadays I use mostly Fedora and LMDE. I lack build experience on those systems, but when the wiki is updated with R14 installation links, I will test installing TDE on those two distros.
Opinions about icons and themes are subjective, but even while CrystalSVG remains the default icon theme, little testing has been performed using non Trinity icon sets. TDE should support all icon theme, no debates. Today I ran a test with the gnome-icon-theme and had problems with icons not appearing correctly (resulting in the infamous Empty icon). I will file a bug report but I have not looked into possible causes. This should be an R14.0.1/R14.1.0 priority.
In a quick test, tdenetworkmanager (and tdepowersave) appeared on a new fresh R14 desktop. The trick was simply installing the packages, which on my desktop is not the norm. My thinking is tdenetworkmanager and tdepowersave should be part of the default installation on laptops and live CDs, but should be optional on desktops/workstations. I don't know whether a distinction is possible during package installation, especially since TDE is not a default desktop and installed after a distro is installed. In that case, I lean toward including tdenetworkmanager and tdepowersave as part of the minimal TDE package set.
I do not have a webcam, but as that is standard for many users nowadays, that should be tested as much as possible.
For distros that support required depenencies (Debian, Ubuntu, Fedora, etc.), avahi should be a required package. Avahi is pretty much standard on most distros anyway, but explicitly including that dependency avoids problems.
I have read Dedoimedo's articles for many years. I am certain that if he reviews R14.x.x he will immediately focus on the faults he found in the January review. That is how he typically reviews software.
Darrell
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA224
To late to test for the offical R14.0.0 release, but better late than never (R14.0.1). Some Trinity (TDE 3.5.13.x) quirks noted in a January 2014 review by Dedoimedo:
http://netrunner-mag.com/they-called-it-trinity/
- Difficulty installing from repositories.
As far as I know this has been resolved with the new mirroring system.
- The default icon theme felt outdated.
Subjective.
- No network manager tool was available in the default desktop.
A valid concern; fixing this is a simple metapackage tweak.
- Embedded webcam did not work.
Not sure how this is our problem? Sounds like a kernel issue.
- Zerconf did not work because avahi was not installed.
Some people like avahi, others (myself) hate it. Not sure that this should be anything other than a suggests package?
His conclusion:
"TDE must be a completely simple and smooth framework, otherwise it stands no chance against the competition. This is the prerequisite, even before you start thinking about discussing the pros and cons of its layout, use and whatnot. It must be as trivial as all others."
Thanks for bringing up this information!
I am still working on the R14 press release; it should go out later today.
Tim
On Mon December 15 2014 15:18:38 Timothy Pearson wrote:
As far as I know this has been resolved with the new mirroring system.
Kuiper seems to have stopped updating many days ago. Copernicus then updated for a while but hasn't as far as I can see updated in at least three days. It seems to have roughly 26% of R14 final but it doesn't seem to be used by the redirector.
(I have not seen nightly builds being mirrored so I don't know why mirrorservice.org is no longer updating.)
Consequently significant portions of each install are served from the master server at lower speeds over the congested uplink. I've seen downloads from the master server at reasonable speeds but I've too often seen them crawling at 8KBps.
In short the new system seems to be reliable but slow for regular installs and upgrades. When R14 Final attracts more downloaders I would expect further declines in download speeds. Meanwhile for those of us who need to create local partial mirrors the new mirroring system is unusable until a complete and consistent mirror forms.
--Mike
On Monday 15 December 2014 15:23:42 you wrote:
On Mon December 15 2014 15:18:38 Timothy Pearson wrote:
As far as I know this has been resolved with the new mirroring system.
Kuiper seems to have stopped updating many days ago. Copernicus then updated for a while but hasn't as far as I can see updated in at least three days. It seems to have roughly 26% of R14 final but it doesn't seem to be used by the redirector.
(I have not seen nightly builds being mirrored so I don't know why mirrorservice.org is no longer updating.)
Consequently significant portions of each install are served from the master server at lower speeds over the congested uplink. I've seen downloads from the master server at reasonable speeds but I've too often seen them crawling at 8KBps.
In short the new system seems to be reliable but slow for regular installs and upgrades. When R14 Final attracts more downloaders I would expect further declines in download speeds. Meanwhile for those of us who need to create local partial mirrors the new mirroring system is unusable until a complete and consistent mirror forms.
--Mike
How about making usbkeys available with a mirror on it . For Debian, top level of /debian would be nice.
You can get smaller sized usbkeys at Amazon, 8gb for $5, not sure how much I would pay for this service ...it is worth something though.
"Never underestimate the bandwidth of a station wagon full of tapes"
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA224
On Monday 15 December 2014 15:23:42 you wrote:
On Mon December 15 2014 15:18:38 Timothy Pearson wrote:
As far as I know this has been resolved with the new mirroring system.
Kuiper seems to have stopped updating many days ago. Copernicus then updated for a while but hasn't as far as I can see updated in at least three days. It seems to have roughly 26% of R14 final but it doesn't seem to be used by the redirector.
(I have not seen nightly builds being mirrored so I don't know why mirrorservice.org is no longer updating.)
Consequently significant portions of each install are served from the master server at lower speeds over the congested uplink. I've seen downloads from the master server at reasonable speeds but I've too often seen them crawling at 8KBps.
In short the new system seems to be reliable but slow for regular installs and upgrades. When R14 Final attracts more downloaders I would expect further declines in download speeds. Meanwhile for those of us who need to create local partial mirrors the new mirroring system is unusable until a complete and consistent mirror forms.
--Mike
How about making usbkeys available with a mirror on it . For Debian, top level of /debian would be nice.
You can get smaller sized usbkeys at Amazon, 8gb for $5, not sure how much I would pay for this service ...it is worth something though.
"Never underestimate the bandwidth of a station wagon full of tapes"
-- Peace,
Greg M Archive SCC
This is a good idea; even better would be a TDE branded drive if they could be obtained cheaply. I know some fundraising ideas were bantered about earlier, then they died as I didn't have the time to look into them. I should resurrect those ideas. :-)
Would $15 + shipping be acceptable for a full Debian/Ubuntu mirror on a USB key?
Tim
On Monday 15 December 2014 17:58:37 you wrote:
On Monday 15 December 2014 15:23:42 you wrote:
On Mon December 15 2014 15:18:38 Timothy Pearson wrote:
As far as I know this has been resolved with the new mirroring system.
Kuiper seems to have stopped updating many days ago. Copernicus then updated for a while but hasn't as far as I can see updated in at least three days. It seems to have roughly 26% of R14 final but it doesn't seem to be used by the redirector.
(I have not seen nightly builds being mirrored so I don't know why mirrorservice.org is no longer updating.)
Consequently significant portions of each install are served from the master server at lower speeds over the congested uplink. I've seen downloads from the master server at reasonable speeds but I've too often seen them crawling at 8KBps.
In short the new system seems to be reliable but slow for regular installs and upgrades. When R14 Final attracts more downloaders I would expect further declines in download speeds. Meanwhile for those of us who need to create local partial mirrors the new mirroring system is unusable until a complete and consistent mirror forms.
--Mike
How about making usbkeys available with a mirror on it . For Debian, top level of /debian would be nice.
You can get smaller sized usbkeys at Amazon, 8gb for $5, not sure how much I would pay for this service ...it is worth something though.
"Never underestimate the bandwidth of a station wagon full of tapes"
-- Peace,
Greg M Archive SCC
This is a good idea; even better would be a TDE branded drive if they could be obtained cheaply. I know some fundraising ideas were bantered about earlier, then they died as I didn't have the time to look into them. I should resurrect those ideas. :-)
Would $15 + shipping be acceptable for a full Debian/Ubuntu mirror on a USB key?
Tim
I would pay $15, that is a good starting price for a mirror of the archive.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA224
On Mon December 15 2014 15:18:38 Timothy Pearson wrote:
As far as I know this has been resolved with the new mirroring system.
Kuiper seems to have stopped updating many days ago. Copernicus then updated for a while but hasn't as far as I can see updated in at least three days. It seems to have roughly 26% of R14 final but it doesn't seem to be used by the redirector.
(I have not seen nightly builds being mirrored so I don't know why mirrorservice.org is no longer updating.)
Consequently significant portions of each install are served from the master server at lower speeds over the congested uplink. I've seen downloads from the master server at reasonable speeds but I've too often seen them crawling at 8KBps.
In short the new system seems to be reliable but slow for regular installs and upgrades. When R14 Final attracts more downloaders I would expect further declines in download speeds. Meanwhile for those of us who need to create local partial mirrors the new mirroring system is unusable until a complete and consistent mirror forms.
--Mike
Thanks for the info. How are you determining the percentage of final?
I'm starting to think mirrorservice.org has a problem of some kind; for the past day or so I saw no attempts to connect which is strange if the mirroring is stalled as you say. There is now an active upload in progress, so we'll see what happens in the next day or two.
At least the system now degrades gracefully instead of causing the showstopper failures Darrell was alluding to that were unfortunately characteristic of previous releases.
For the next SRU I'm going to see if I can set up a more stable layer in between the TDE servers and mirrorservice.org.
Tim
On Mon December 15 2014 19:02:31 Timothy Pearson wrote:
Thanks for the info. How are you determining the percentage of final?
Assuming the 11/12 Packages.gz is final, iterate through it and see how many of the "^Filename: " are present. Initially I was doing this for Wheezy and recently for Jessie but based on observed mirror behavior I think this is representative as all distros of each package+version tend to mirror together.
In addition to different results from kuiper, copernicus, and mirrorservice.org, I've also been seeing different results using http versus rsync. Color me confused.
At least the system now degrades gracefully instead of causing the showstopper failures Darrell was alluding to that were unfortunately characteristic of previous releases.
Yes, that's a significant improvement.
--Mike
Hi Tim,
Tests every six hours showed kuiper mirroring strongly for a while and reaching approx 60% of R14 Final but then nothing in last six hours.
--Mike
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA224
Hi Tim,
Tests every six hours showed kuiper mirroring strongly for a while and reaching approx 60% of R14 Final but then nothing in last six hours.
--Mike
Logs here show no transfers of anything but the CD images, which for some reason kuiper wants to re-download constantly. This is all very strange; unfortunately I think the only recourse here is to, as mentioned before, switch primary mirror providers. I'm not going to look at this until early next year as the risk of breakage is too great to ignore in light of the recent R14 release.
Tim
On Tue December 16 2014 14:15:05 Timothy Pearson wrote:
Logs here show no transfers of anything but the CD images, which for some reason kuiper wants to re-download constantly.
I don't think its a timestamp problem or else things would probably be worse. Could be a disk error causing their rsync to abort.
Could it be running into a disk space quota?
--Mike
-
Area02 SCC -
Darrell -
Greg Madden
-
Mike Bird -
Timothy Pearson