withgusto ZNC Migration (3/18/16, 9 PM - 12 AM EDT) EDIT: Important ZNC Form! As you may have heard, withgusto is undergoing a major downsizing to ensure viability in the future. As part of this plan, we are moving ZNC to a different, separate server to allow ZNC to operate independently of withgusto's main server, hopefully increasing the stability of both for times to come.
What does this mean for you?
There will be downtime for around three hours from 9:00 PM - 11:59 PM EDT this Friday, March 18th, 2016. ZNC will be completely disconnecting during this time. The downtime may be shorter depending on how things go, but don't count on it! If you maintain ops yourself, you should make sure to log in manually to keep ops during this time.
RDNS will be changed around 5 PM EDT this Friday, March 18th, 2016. Avoid reconnecting to IRC from ZNC during this time if you depend on hostname recognition!
After the move, your account and quality of service will NOT be affected. (In fact, we hope that it is MUCH better!)
We will be changing the login server once more. The hostname should stay the same - znc.withg.org. The only thing that will change is how you access ZNC. If you signed up on the form below, you will get an email soon on the change in login server. Please keep it private!
We will update everyone if there are any changes to this plan, as well as during and after the migration.
We apologize for this downtime, and as always, we thank you for flying withgusto! ✈
If you have any questions, comments, or concerns, feel free to ask away in this thread!
Updates:
[3/18/2016 10:14 AM] We will be changing the login server once more. If you signed up on the form above, you will get an email soon on the change in login server. Please keep it private!
[3/18/2016 10:14 AM] All preparations have been made for the move. Please get ready for the switch as soon as possible.
[3/18/2016 8:36 PM] Migration will occur in less than 30 minutes! Please backup ops for your channel, and get ready for the switch! Remember, the service will be down for around 3 hours, or until things are completely set up!
Introduction It has been a year since the last withgusto update.
About a year or so ago, a massive DDoS attack took withgusto down. This caused a "strike" to occur with the VPS hosting provider, and I temporarily closed withgusto's doors - specifically, hid it behind Cloudflare. This allowed Cloudflare to temporarily take the hit and reduce the load on the VPS. However, this had the effect of also blocking SSH, which was a lifeline into withgusto. Without a doubt, this is probably what drained significant use of withgusto.
Unfortunately, due to many commitments, I never got a chance to move withgusto. A year has passed, and withgusto is becoming increasingly difficult to maintain, both in terms of time and money. As such, regretfully, I must make the decision to wind down withgusto.
Note that this is NOT a shutdown - but we are planning on significantly reducing resources.
withgusto Downsizing The proposed plan:
Reduce memory availability from 1 GB RAM to 128 MB - 256 MB
Significant memory usage is from clamd/amavisd/maild/spamd - around ~34.6%, or 354.3 MBs. mail@withg has been inactive for quite a while, mainly due to significant configuration issues. We are planning on removing this from withgusto, since mail services are difficult to maintain, and there is very little use of this service.
Deluge (web torrent client) takes around ~2.5%, or 25.6 MBs. We are planning on removing this from withgusto, since it's tough to maintain a client and not get into trouble for bandwidth/DMCA.
Current memory usage is 523 MBs. Subtracting all of these, 523 MBs - ~380 MBs = 143 MBs.
Depending on services people still want, and depending on how we shuffle things around, we may bring this down even further to <100 MBs. User programs and websites will fill the rest.
Reduce CPU cores from 2 to 1
We have rarely seen anyone use more than one CPU. Two CPUs is useful for compiling, but compiling doesn't happen too often - and VPS providers don't like constant CPU usage! Actual CPU speed will remain the same, just the number of cores will be reduced.
Use OpenVZ instead of KVM (less kernel control)
We have rarely used any features that would require a different kernel. All IPTables and advanced networking features are enabled in OpenVZ. Resources are allocated somewhat differently, but they should not have an impact on us.
OpenVZ is drastically cheaper than KVM (less VM). As such, this makes OpenVZ an appealing option going forward.
Disable backups for user data
At the moment, we pay for a backup service that we've (fortunately) never had to use. However, it incurs significant monthly cost, and as such, we will be phasing out automatic backups.
In the future, we may opt to use a free cloud storage service for backups to save money and achieve the same effect. However, we can NOT guarantee that this feature will arrive anytime soon - as such, you will now be responsible for your own data!
That said, before we move, user data folders (including /var/www/USER) will be backed up and offered to those who no longer wish to use withgusto.
Migration of user data ONLY - system will be cleanly installed
The current OS is very, very old - we're still using Debian 6, and the latest is Debian 8!
As such, we will be using Debian 8 in the future.
User data is easy to copy, but system data... not so much. If you have any system data that you want us to keep, let us know!
Future of withgusto Services Service plan (some already mentioned above):
Mail service will be terminated. We don't see many (if any at all) using this, and this has been difficult to maintain. Moving forward, we will no longer host mail here.
Deluge (web torrents) will be terminated. Tough to maintain, and there are some other free/cheap options out there for your torrenting needs.
ZNC will be moved to a separate server/service from withgusto. We plan on running ZNC on a much lighter server - we've done some experiments, and it looks like it will work perfectly. It also allows us to improve stability, since withgusto is separate.
Omnimaga IRCd will be preserved - may either move to ZNC's location or withgusto - still deciding.
Depending on movability, user-installed services will be moved to the new server as well.
Other services will either be terminated or moved - we need to comb through them in the next few days!
withgusto Finances Without a doubt, these are very tough cuts in service. The decision to cut these services was not taken lightly - however, in order for withgusto to continue (and not completely drop dead), we need to reduce these services and move to a lighter server.
Currently, I pay $15/mo for the main withgusto server, $15 for the backup service, $25/year for the backup.withg server, and around $16/year for the domain. Total yearly = ~$400/year!
With the new plan, I'm hoping to reduce this cost to something like this: $32/year for the main withgusto server, $15/year for the backup.withg/IRC/ZNC server, and around $16/year for the domain. Total yearly = ~$63/year... much more affordable!
Conclusion All of this said, we still want your feedback! We don't want to move forward without hearing from you guys - if you don't like the things above, let us know and we'll try to accommodate! Since it has been a long time since we've had service, we want to hear from you in terms of how you will be using it.
Migration is NOT happening yet! Once we have some feedback, we'll announce dates for migration.
Officially, withgusto will close down starting today. Unofficially, it was shut down a few months ago, right after the DDoS attack.
We no longer have the resources nor time to write code, manage the server, run our services, and purchase server capacity. This is evident with our downtime for the last 3 months.
For those who have data on our server, we are providing a request form for backups: http://withg.org/backup/
Please submit a request as soon as possible, and our backup script will create a backup within 24-48 hours.
Data will be permanently erased within 7 days. Backups that are not made are subject to data sale to 3rd party advertisers, as a way of recouping the costs of the server.
In the mean time, air forces rcfreak0 and Eeems are available to help transition your move to their servers.
Thank you to those who decisively flew withgusto. It has been a great ride, but as the captain, we must come to a landing and to an end.
Thanks everyone for a great 6 years!
Sorry for the troubles, Captain alberthrocks
EDIT: APRIL FOOLS! Though it looks like many people took it seriously... :p
Dubbed Cloudflare Universal SSL, they are now offering free SSL to everyone, including free plans! This includes if you are running a non-secured (no HTTPS) website, in which they will still give you HTTPS, but warn you that their server to your website will be unencrypted. (Do NOT try to run a e-commerce website if this is the case!)
The catch? For free users, they are deprecating support for older browsers by enforcing newer security standards - ECDSA and SNI. (ECDSA is a newer and more secure encryption algorithm, and SNI is just a way to emit different SSL certificates from one IP!)
SNI support:
Quote
Desktop Browsers
Internet Explorer 7 and later
Firefox 2
Opera 8 with TLS 1.1 enabled
Google Chrome: Supported on Windows XP on Chrome 6 and later Supported on Vista and later by default OS X 10.5.7 in Chrome Version 5.0.342.0 and later
Safari 2.1 and later (requires OS X 10.5.6 and later or Windows Vista and later).
Note: No versions of Internet Explorer on Windows XP support SNI
ECDSA support gets murky, though. According to Cloudflare, it is not available on Windows XP (and below), or anything older than Android 4.0 ICS. To clarify, they're saying you MUST have Windows Vista (and newer), as well as Android 4.0 ICS (and newer).
...but wait! Does that mean everyone using Windows XP is screwed? Not quite. According to https://github.com/client9/sslassert/wiki/IE-Supported-Cipher-Suites, SSL support for IE depends on the OS's SSL support. Running IE8 on XP means that the SSL support will suffer, since IE8 will use XP's SSL support, which doesn't have the new ECDSA. (Not totally sure about SNI, though.)
So what does Firefox and Chrome use? They use their own library called NSS, which is their own SSL stack that supports EVERYTHING - so as long as you're running a pretty recent version of Firefox/Chrome, you're fine! Safari/Opera support is still unknown though. Supposedly, Opera should be using NSS since they've moved to Chrome's core, but not too sure...
In Plain English If you're on Windows XP and you use IE: regardless of version, you will NOT be able to access a Cloudflare SSL secured site. If you're on Windows XP and you use the latest Firefox/Chrome: you WILL be able to access a Cloudflare SSL secured site. If you're on Windows Vista and you use the latest browser: you WILL be able to access a Cloudflare SSL secured site. If you're on Linux and you use the latest browser (with a recent OpenSSL): you WILL be able to access a Cloudflare SSL secured site. If you're on Android and you use Android ICS 4.0 or later: you WILL be able to access a Cloudflare SSL secured site. If you're on iOS/Mac OS X and/or using Safari/Opera: UNKNOWN. See the next section for more details.
Finding out if you have ECDSA/SNI: A lot of websites run with Cloudflare (including Omnimaga) - however, many will probably wait to see whether SSL support is available yet for a good amount of platforms.
We’re finally moving! Unlike last time, we plan to actually get it done this time... hopefully. More importantly, the methodology for migrating from our old servers to a shiny new one will be different. Really different. Old versus New (or: how not to fail at migration again)
Unlike last time, we will NOT be using an automated tool to migrate everything. (No worries, if you’re looking for that magical tool, it’s still in development, but it’s easier to test it on a physical computer than a virtual server...) In addition, we will not backup as much data as we did last time. This time, we will hand pick directories that the withgusto administrators deem to be core to withgusto services. The good news? We’ll make sure your data gets to the new server safely. Bad news? If you’re a weirdo (as in someone who doesn’t store all of their data in their home directory, /var/www/username, or in an active core service offered by withgusto), you may be out of luck. What does it mean? It doesn’t mean we’re tossing your data in the trash - I think pitchforks might come haunt us if we did that - but it does mean that you are 100% responsible for backing up (and moving it) yourself. We will give you plenty of time to do the move - but you must do it yourself.
The sky is falling! AHHH!
No worries, we have one other thing. If you are a weirdo, BUT your data is consolidated and you are able to set things up by yourself, you can tell us which directories you want us to move, and we’ll happily move them for you, gratuit. No hidden fees. The only condition is that the files MUST be simple to move. If it’s a tangled web of symlinks, or scattered files throughout the file system... we’ll probably have to ask you to move that. (It’s for your own good - if we forget to move complicated files, or something goes wrong, it’s going to go bad for both of us! We want to make sure that everything makes it to the new server safely!)
OK, what now?
The migration, like last time, will take place in stages. Of course, we’ve learned our lessons from last time, so the stages will be very different. STAGE I: Announcement of Migration Files and Folders + Backup Survey
At this point, we announce the files and folders that we will move. At this time, we will ask withgusto users to help out by compressing files and moving large files off the server so that we can prepare to backup everything. We didn’t forget about backup2, either - we will also announce files and folders for that as well. At the same time, we will also open a survey for files and folders to move for the oddballs out there. This survey will be used to determine additional files and folders to backup. We will also make sure we truly back up everything - if we forgot anything, please let us know! The new server will also be up on new.withg.org for those who would like to do initial migration stuff. Finally, we’ll announce dates for STAGE II and STAGE III - at STAGE II, the survey will close. STAGE II: User Directory Lock + Initial Migration Starts
At this point, withgusto users will no longer be able to login, and the migration process will begin. The initial migration process will simply be moving files to the new server, re-creating the users, and setting the appropriate permissions. At this time, we will have finalized the list of important withgusto files and directories to back up, and we’ll list them in our post for STAGE II. The survey will be closed, and the files and directories that we’ve approved to backup will be listed as well. STAGE III: User Directory Unlock + Service Migration Starts
At this point, users will be able to login again to perform manual migration. At the same time, withg.org will be renamed to old.withg.org, and the new withg server will be renamed to withg.org. Why? Service migration, of course! We hope to have most of the services up and running on the new server. Of course, we don’t like downtime as much as the next person, so we’ll keep the old server’s services running, and gradually have people migrate over to the new server via simple DNS propagation. This stage will last for around 2 weeks.
STAGE IV: Old Server Termination Warning + Old Service Termination
At this time, we will post a warning for the old server’s termination. We will also terminate the old services in favor of running solely on the new server. We will merge any data, if necessary, and then shut down the old withgusto services for good! At this time, any files that need to be backed up should be backed up now! This stage will last for around a week.
STAGE V: Old Server Termination
For the last and final stage, we will announce a 3-day grace period for shutting down the server. Once that grace period is over, we’ll shut it down... and wait for another 4 days for any last-minute requests! After a combined total of a week, the old server will finally be terminated. Like the previous stage, this stage will last for around a week.
And finally...
STAGE 0: Announcement and Preparation!
We’re at this stage - announcing our intent and allowing everyone to prepare! One other thing we didn’t mention... if everyone on withgusto agrees to move onto the next stage, we can make the transition MUCH faster! We can do this with the following:
Notify withgusto users you know about the migration!
Help us out by backing up your larger files and directories, and removing them from the server! (No worries, if you need a secondary backup, you can upload them back on the new server once it’s up!)
Check and make sure you aren’t “weird”. If you have files elsewhere, make a note of it! Try to backup it beforehand - if you can’t (or don’t want to), write down where it is and let us know in the survey!
Final Total Time: around 6 weeks... or less!
...and that’s pretty much it! Let us know if you have any questions, comments, or concerns!
Apparently this new startup (and product) is going crazy! They launched on Monday, and have raised $114,860/$20,000, 574% of their goal! Apparently they're also backed by the UC Santa Barbara Technology Management Program, but that's another story...
Isn't it such a bummer when you lose your keys or wallet? Every time I lose something, I spend 20 minutes looking for my keys only to find them hiding in the most obvious place, possible - usually in yesterday's jeans or under the couch cushion.
That's why we invented TrackR, a simple way to keep track of items using your smartphone. After 5 years of R&D, thousands of customer feature suggestions, and 5 product revisions, we are proud to reveal TrackR bravo to the world. TrackR bravo is the slimmest and most elegant item tracking device ever created backed by the world's largest Crowd GPS network.
I just bought one (or two, actually!), since these guys are pretty legit. Anyone else getting one?
Disclaimer: Links are referral links - you can get one for free when referring another friend/person! I actually like the product, having gotten one for free from here. They're a legit business, so go and support them!
UPDATE: Specifics and clarifications can be found here.
Here's something that came up at work today. Seemingly simple, but it's a lot more complicated than it looks! (At least for me, heh...) I've came up with a solution already, so try it out!
The challenge (if you can't access the above): ===================== = Make That Table! = ===================== CHALLENGE: Using any programming language, write a program that takes the following INPUT and converts it into a valid table OUTPUT. Input represents any table, space-delimited. The first line is the table header, and the second line is the table secondary header.
Output must be based on the input. Display statements of the final result without any steps to get to the final results will be disqualified.
======================================================================= = INPUT: = ======================================================================= Hoooligans! Party Animals Count Alpha_Delta Rounded First Second Third 1234 12.4562294932 12.4958 193583.149592983 28592 2948502.5 39502050 104.682950380298 193.499499 19384885444.2223 1234567 123592
CLOSED This VPS has been leased to Juju. Any further inquiries about the VPS should go to Juju, as he has already paid for 2-3 months.
Original offer below.
Spoiler For Spoiler:
As part of withgusto's consolidation, a cheap VPS that we got a while ago will now be sold!
It's a decently priced VPS, with the following features:
OpenVZ powered
2 GBs RAM
50 GBs HDD
2 TBs bandwidth
Full control (root, OS install, etc.)
And the price for this monster? Just $7/month! This VPS is perfect for hosting game servers (like Minecraft), a website, anything! :D
There are two options for getting this VPS:
Full ownership - you can take the entire VPS for yourself! Account details will be transferred over to you. An additional (but small) one time fee applies.
Leasing - you can "rent" the VPS from me, and you can have majority "stake" in the VPS.
This VPS is only available to current members only. Any members that registered after this post are not allowed to buy/rent this VPS.
If you're interested, let me know! The VPS is set to disappear on January 19th, 2014, so if you want it, let me know ASAP!
It's quite late - I was going to call this a Christmas present, but it's 4 days after Christmas, so I'll call this an early New Year's gift.
For quite a while, Debian and Ubuntu users have been depending on the install_tilp.sh script from the TiLP SVN repository to build packages... which meant installing a lot of development packages, compilers, etc. that one might not want or need. This was due to the lack of updates from both the Debian and Ubuntu sides, mainly Debian.
That said, I recently took over package maintainership (though I'm an "intern", so I don't have full upload rights yet). However, due to the closing of the repositories in preparation for the Debian 7 release, you won't see anything until next year.
At the same time, I also decided to package the new TilEm Z80 emulator, so expect to see that soon!
However, rather than wait for people to get their hands on some Debian packages, I've went and built them myself, and placed them into an APT repository for you guys to use.
Installation
Debian:
Spoiler For Instructions to add the Debian repository:
You're done! If you have previously installed TiLP and friends, you should now be asked to upgrade. If you haven't, just install packages normally - tilp2, gfm, and tilem.
Ubuntu: Ubuntu users must wait for about a week or two. Packages for Ubuntu will be hosted on the Omnimaga PPA. However, due to some complications, some packages had to removed, which takes about 1-2 weeks. This post will be bumped and updated when those packages are ready.
Acknowledgments Simply the best for the last.
Really, really big thanks to Lionel Debroux and Benjamin Moody for helping out with the packaging! Most maintainers don't get much help from the original program developer, but you guys are exceptions! We fixed a lot of problems with both TiLP and TilEm together, and of course the original packages themselves!
Another big thanks to jacobly, who gratefully donated his time to helping out with the debian/copyright work (and even developed a script to create the file automagically!). No Debian Developer would have accepted any packages without your help! (After a while, he threw up his hands in the air and gave up - well, not really, but he definitely paused his work out of understandable boredom. )
Also thanks to #debian-mentors(at OFTC, irc.oftc.net) for the constant help with my packaging! (Particularly paultag, daemonkeeper, and my mentor, algernon!) My constant questions probably seemed endless and stupid, but you guys answered them anyway, even when I should have RTFM...
Additional thanks to Catherine(on #cemetech, also previously known as _player) and jacobly (again) for the extensive Bash scripting expertise. Those questions weren't random - they were all part of this project!
Finally, another BIG thanks (heck, all of these were BIG) to Sorunome, who generously lent me his server for 64-bit package building. His server may be small, but it certainly can (and will continue to for the foreseeable future) build 64-bit Debian packages!
Spoiler For FAQ:
Frequently Asked/Anticipated Questions: General Questions:
I love your packages! OR - Something didn't install correctly/broke! Who should I praise/complain to? I maintain all packages, so you can either send me adorations or whine/complain to me. This topic is a good place to report problems. Depending on how busy I am, I may get back to you within the day, or within a month.
I want to help! Who should I contact? What do I need to know? I currently maintain the package with another co-maintainer, jacobly. It's best to contact me, though you can also contact him and he can get you started. You should be able to read and follow specs, and know some basic Bash scripting. Knowledge of sed and awk is a big plus.
Could you package for Fedora, Arch, [distro goes here]? No, I'm just a Debian packager, and will probably stay that way for the foreseeable future. AFAIK, TC01 manages the Fedora packages, and Jonimus manages the Arch (AUR) packages. If you want to get packages for another distro... try doing them yourself!
Is the packaging work open source? Yes - you can (technically) build these packages yourself! (Of course, you need to install the needed dependencies.) The project can be found here: https://code.google.com/p/tilp-debian/
Note that it has not been updated with the latest changes, so things may not work perfectly yet.
Can I upload a package to your repo? Yes - this is technically a community repo, so you can contribute to it! You may upload packages to apt.withg.org under two conditions: 1) it is useful to the community (and obviously not harmful), 2) the package is properly formatted according to the Debian packaging guidelines.
General Packaging Questions:
Do you build for 64-bit systems? Yes, I do - the amd64 variant, that is. (If you don't know what amd64 is, don't worry about it - just know that it's 64-bit!
Will you package the latest Git/SVN version of TiLP? Maybe - if I can figure out how to do it. (I'm sure it's possible, because there are package versions tagged with "git20101104" and the like.) I'll let you guys know if I do release such a package - though you may have to add a different repo channel (i.e. apt.withg.org wheezy-git main), as the versions will conflict with the existing packages.
How often will these packages be updated? I'll try to make an update within 1-2 months of a new release, but no guarantees. The next release is expected to have a LOT more dependencies (which I need to package, as they don't exist in Debian yet), so expect some delays.
When the Debian/Ubuntu package arrives for TiLP, libti*, GFM, and TilEm, do I have to remove the PPA/3rd party repo? No - the versioning of the package (the "~DISTRO" suffix/tag) makes the package inferior to a package without it, aka the official repository ones. When the time comes, you can simply update to your distro's version of the package.
Why are ROM dumpers disabled in TiLP? To be more precise, it's disabled in the libticalcs library. If you notice the versioning of the libticalcs package, it's tagged as "+dsfg", or "Debian Free Software Guidelines." This is due to the Debian philosophy:
"If you are on a desert island, magically with a computer, a Debian CD, and the Debian repository servers connected to some extraterrestrial power source, you must be able to rebuild a package in its entirety from source."**
libticalcs has assembled ROM dumpers that can not be built with tools in the Debian repository, so they are considered "non-free" (which is "taboo" in Debian). Rather than place libticalcs in non-free (and screw up all the other packages), they are simply disabled, causing the package to get the +dsfg tag. This will be fixed in the next release, since the new assemblers (written by Ben Moody) can be assembled by FOSS tools that I can package. (Some of the old ones required TASM, which is closed-source.)
(In reality, despite the inclusion of a patch to notify people about the problems with the packaging, I don't think the ROM dumpers are actually removed. You might just have the ROM dumpers built in after all!)
Ubuntu Specific Questions:
Why are the Ubuntu packages delayed? Better yet, why can't you build them yourself? Ubuntu packages are delayed because we use Launchpad's PPA to host and build packages, and the system isn't exactly stellar. Deleting packages are "requests", and they can take up to 1-2 weeks to process. Uploading a higher version would also do the trick, but the old packages would still remain, which may cause significant problems in the future.
As for personally building the packages myself - I could. (In fact, my repo scripts have support for building Ubuntu packages, just needing a few tweaks here and there to make things work.) The problem is that Ubuntu (or rather, Canonical) recently decided to remove a good majority of their old repositories, making package building for old Ubuntu distros impossible. As of now, the only way to build for old versions of Ubuntu (like maverick 10.10) is via Launchpad. It's pretty stupid, considering that Debian has its own archive] packages, and Jonimus manages the Arch (AUR) packages. If you want to get packages for another distro... try doing them yourself!
General Packaging Questions:
Do you build for 64-bit systems? Yes, I do - the amd64 variant, that is. (If you don't know what amd64 is, don't worry about it - just know that it's 64-bit!
Will you package the latest Git/SVN version of TiLP? Maybe - if I can figure out how to do it. (I'm sure it's possible, because there are package versions tagged with "git20101104" and the like.) I'll let you guys know if I do release such a package - though you may have to add a different repo channel (i.e. apt.withg.org wheezy-git main), as the versions will conflict with the existing packages.
How often will these packages be updated? I'll try to make an update within 1-2 months of a new release, but no guarantees. The next release is expected to have a LOT more dependencies (which I need to package, as they don't exist in Debian yet), so expect some delays.
When the Debian/Ubuntu package arrives for TiLP, libti*, GFM, and TilEm, do I have to remove the PPA/3rd party repo? No - the versioning of the package (the "~DISTRO" suffix/tag) makes the package inferior to a package without it, aka the official repository ones. When the time comes, you can simply update to your distro's version of the package.
Why are ROM dumpers disabled in TiLP? To be more precise, it's disabled in the libticalcs library. If you notice the versioning of the libticalcs package, it's tagged as "+dsfg", or "Debian Free Software Guidelines." This is due to the Debian philosophy:
"If you are on a desert island, magically with a computer, a Debian CD, and the Debian repository servers connected to some extraterrestrial power source, you must be able to rebuild a package in its entirety from source."**
libticalcs has assembled ROM dumpers that can not be built with tools in the Debian repository, so they are considered "non-free" (which is "taboo" in Debian). Rather than place libticalcs in non-free (and screw up all the other packages), they are simply disabled, causing the package to get the +dsfg tag. This will be fixed in the next release, since the new assemblers (written by Ben Moody) can be assembled by FOSS tools that I can package. (Some of the old ones required TASM, which is closed-source.)
(In reality, despite the inclusion of a patch to notify people about the problems with the packaging, I don't think the ROM dumpers are actually removed. You might just have the ROM dumpers built in after all!)
Ubuntu Specific Questions:
Why are the Ubuntu packages delayed? Better yet, why can't you build them yourself? Ubuntu packages are delayed because we use Launchpad's PPA to host and build packages, and the system isn't exactly stellar. Deleting packages are "requests", and they can take up to 1-2 weeks to process. Uploading a higher version would also do the trick, but the old packages would still remain, which may cause significant problems in the future.
As for personally building the packages myself - I could. (In fact, my repo scripts have support for building Ubuntu packages, just needing a few tweaks here and there to make things work.) The problem is that Ubuntu (or rather, Canonical) recently decided to remove a good majority of their old repositories, making package building for old Ubuntu distros impossible. As of now, the only way to build for old versions of Ubuntu (like maverick 10.10) is via Launchpad. It's pretty stupid, considering that Debian has its own archive of old distros. Not sure whether it's cost related (Launchpad is pretty wasteful, IMO, so why not save there?) or some sort of plot to get money (i.e. make people dependent on the Launchpad service to build packages).
Ubuntu now has TiLP 1.16. Should I add the PPA? I highly recommend doing so. The reason is that the Ubuntu devs were silly enough to just update TiLP, and not any of its libraries. (See: LP#1010222) That means TiLP will look prettier, but still fail to work and crash. If you add the PPA, you'll get the newer libraries, and TiLP will (hopefully) start working again! Worse case scenario: TiLP doesn't run anymore from the new libraries (unlikely, but possible). You can easily open Synaptic, select the tilp2 package, and change the version (Force Version) to the PPA's version, and everything should work.
** I wasn't kidding - see here. I might have bent the scenario just a bit, but the gist is pretty much the same.
Just so that updates are more public, I've decided to post them here! You can also discuss any problems, ask questions, and make requests here as well.
Fr33 5h311 accounts are still available! It's 100% free! We simply ask that you be respectful to others on the server and outside of it, and that you occasionally put some change in the tip jar for withgusto. You should be a member of Omnimaga for at least a month before signing up.
Spoiler For S3rv3r sp3cs:
S3rv3r 1 (main s3rv3r):
K|V|M V1rtual1zat1on (no overselling!)
Intel(R) Core(TM) i7-2600 CPU @ 3.4 GHz, 2 cores
1 GB RAM
40 GB HDD
1OO MB1t/s n3tw0rk
Debian 6 32-bit (when Debian 7 is released, will be upgraded to Debian 7 64-bit)
S3rv3r 2 (secondary s3rv3r):
0penVZ V1rtual1zat1on (overselling possible)
Not as reliable! (But very well spec'ed!)
Intel(R) Xeon(R) CPU L5410 @ 2.33GHz, 4 cores
2 GB RAM
50 GB HDD
1OO MB1t/s n3tw0rk
Debian 6 32-bit (when Debian 7 is released, will be upgraded to Debian 7 64-bit)
Spoiler For Features:
An account gets you:
Web space with Python support, latest P|H|P5 support, secure H|T|T|P|S S|S|L, and under a speedy NGINX web s3rv3r!
55H access (duh) with background processes
My!S!Q!L access
5F|T|P access
NodeJS
GCC/G++ compilers
Webma1l (username[at]withg.org)
2NC B0unc3r (by request)
Rem0te deskt0p (by request)
...and more!
Note that res0urc3s may be limited as necessary for user processes on the s3rv3r. Resources are reasonably provisioned by need. No, you can't run a Min3|craft s3rv3r here.
Spoiler For How to get one:
DO NOT POST IN THIS TOPIC. Instead, post in the request topic. Posting in this topic will automatically have your application rejected - don't do it!
You must apply with this simple format: S3rv3r: 1 or 2 Email (please obscure with (at) or similar to prevent spambots): Why do you want it? How you will use the account? Why do you want it fr33? Do I agree to the conditions of respect above? I understand that withgusto is a donation-based service - the availability of this service depends on people like me for donations to pay server costs. I also understand that my account may be terminated at any time. Finally, I understand that I am responsible for backing up, and for actions (good or bad) on the server. Legitimate explanations only! I'm not accepting a dumb, forceful, or crazy explanation. NO EXCEPTIONS.
Spoiler For FAQ:
1) Who manages the s3rv3r? I, alberthrocks, does. I will make sure that the server runs as smoothly as possible, and notify you in advance if any maintenance that will cause downtime is needed. 2) Are I/R/C bots allowed? Yes! However, do note that there are a LOT of my own bots running already on server 1, so availability for EFNet connection may be limited. Remember that any abuse will result in account termination (be respectful to others on the server and outside of it), so please be respectful! 3) What are the limits? We generally don't have limits, but we'll mention some baseline info: 128 MBs of RAM, 1-2 GBs of HDD space, 10-15 processes, overall taking less than 5-10% of C\P\U and/or taking max C\P\U < 3 minutes in a 30 minutes interval. We are very flexible, but again - don't abuse! (Game s3rv3rs eats lots of space and RAM, so that wouldn't work here.) If you use more s3rv3r resources than the limits that we proposed, please consider donating more funds to the network. 4) Are there backups? Yes - we use JungleDisk to backup our servers every 24 hours. Note that JungleDisk does not support fetching files from backup (just restoration to the server). However, we are not liable for backup problems - it is still your responsibility to back up! 5) Will there be FTP? We don't consider FTP to be a safe protocol, and it's troublesome to implement. Nevertheless, we may consider it in the future. 6) Why are some words spelled with numbers? It's to prevent posts like this or this (though the latter turned out to be a staying member, at least for a while).
Spoiler For Admins:
Current admins include:
alberthrocks (me)
geekboy
Eeems
Cooliojazz
(If I forgot to include you, tell me!)
We are pretty busy, but you can contact any of us for support, either on IRC or on the forums. Do NOT contact us for s1gn up requests - they will be rejected. You must s1gn up on the forums like everyone else (see above "How to get one")
Although I am "brave" in programming things, overclocking, etc. etc., I'm a scaredy cat when it comes to upgrading a system. Especially Linux ones. (Blame it on Ubuntu's terrible upgrading.)
I currently have Mint Linux 10, a distribution that's quickly gathering dust. I'm looking for a distro that has up-to-date libraries and programs, but is solid in stability. (That's quite a bit to ask for, eh? ) I'd prefer a Debian-esque system, since I'm already familiar with it and don't want to spend time to relearn it. It also needs to have word processing and web browsing. (Hint: LibreOffice and Firefox) And finally - it needs to be easy to setup (including data reimport). Time is key.
So basically:
Stability is king.
...but of course with some pretty new libraries too!
Debian-esque.
Word processing and web browsing.
Quick and easy to setup.
As for backup and restore, I don't trust MintBackup for that. I want to keep not only /home, but also modified config files and programs that I've installed through the years. What tool would work for that?
This seems like a good idea, so I'm starting the project adoption thread!
I am currently cleaning up my FOSS (free and open source) projects. That said, I've already deleted a few projects that have no code (or are useless). However, there are a few left that have solid code, and instead of throwing them away (and wasting code), they might enjoy another project admin.
Here are the projects that I'm giving away:
LockerzBot: remember when Lockerz used to be that "big thing"? This helped power it! It used to be able to automatically fetch PTZ for you. It's likely that this might still work, with some modifications. (Python, moderate completion, https://code.google.com/p/lockerzbot/)
gWabbitemu: your favorite TI-8x emulator, ported to GTK+ for Linux! If you're looking for a native, GTK+ port of Wabbitemu, this is it! It needs some a LOT of love and caring, but it can be done! (C, little progress, https://code.google.com/p/gwabbitemu/)Adopted by AaroneusTheGreat! Thanks!
These projects will be executed in 2 days, so please, save them from the Project Shelter's wrath!
There is also a special project: This is a project that I am keeping, but I would like some assistance with it! Requirements are that you should be familiar with BASH scripting, love Debian/Ubuntu/Mint, and have lots of time to learn and do things! It's undisclosed, but you will be benefiting the TI calculator Linux community with your work!
Let me know if you're interested in adopting one of these adorable little projects! As always, please demonstrate proof of adopter interest and skill! First come first adopt!
I am currently developing two big projects, one public and one secret! They are both C based, and are very exciting to develop! However... there are always concerning linking problems! The code can be perfectly valid, but it will never compile/link! There are also some interesting features that I would like to see in ndless, which if possible, I'd like to help with.
That said, here are some things that I would like to get fixed: 1) Standard C Library Collisions (or undefined references!) This applies to both projects, though the public one's error messages were shorter and probably easier to fix:
nspire-ld obj/*.o -L./nrgbsdk/lib -lRGB -lgcc -nostdlib -lc -lm -o nrgbwabbit /usr/local/arm/lib/gcc/arm-none-eabi/4.6.3/../../../../arm-none-eabi/lib/libc.a(lib_a-svfscanf.o): In function `__ssvfscanf_r': /home/albert/ndless/modern_toolchain/build/arm-none-eabi/newlib/libc/stdio/../../../../../newlib-1.20.0/newlib/libc/stdio/vfscanf.c:1584: undefined reference to `__aeabi_d2f' /usr/local/arm/lib/gcc/arm-none-eabi/4.6.3/../../../../arm-none-eabi/lib/libc.a(lib_a-syscalls.o): In function `_sbrk': /home/albert/ndless/modern_toolchain/build/arm-none-eabi/newlib/libc/sys/arm/../../../../../../newlib-1.20.0/newlib/libc/sys/arm/syscalls.c:499: undefined reference to `end' /usr/local/arm/lib/gcc/arm-none-eabi/4.6.3/../../../../arm-none-eabi/lib/libc.a(lib_a-strtod.o): In function `strtof': /home/albert/ndless/modern_toolchain/build/arm-none-eabi/newlib/libc/stdlib/../../../../../newlib-1.20.0/newlib/libc/stdlib/strtod.c:1194: undefined reference to `__aeabi_d2f' collect2: ld returned 1 exit statusThis does NOT link to the standard library and instead depends on the ndless syscalls and definitions. However, this causes problems, as seen above. When linking with the standard library, it ends up having multiple definition errors instead. Maybe there could be a define allowing the use of newlib instead?
2) New feature: ELF loader with dynamic libraries support BFLT does *not* implement this at all. Only ELF can load dynamic libraries on the fly (dlopen, dlsym, etc.). This would be very useful for plugin support in my secret project, which works but is very limited without ELF support.
3) Multithreading This may or may not be needed for SDLWabbitemu, but it would be nice to have. tangrs I believe made a proof of concept, and NUCLEUS OS indicates support for it. (Maybe there's a syscall out there?)
4) Secret project with secret changes requested to disable something with a define. (ExtendeD knows what I'm referring to - I am willing to create the patches for that if you don't have time!)
Show Posts
)
