LinuxQuestions.org
Welcome to the most active Linux Forum on the web.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices


Reply
  Search this Thread
Old 08-20-2019, 04:54 AM   #316
zeebra
Member
 
Registered: Dec 2011
Distribution: Mageia, Slackware
Posts: 958
Blog Entries: 11

Rep: Reputation: 271Reputation: 271Reputation: 271

Quote:
Originally Posted by Lysander666 View Post
Yuk, the most repulsive thing I've seen from that thus far is the "empty /etc" section which is absolutely upsetting me. "defaults" and if not defaults then "config". I hate that policy and I think for me it was absolutely disgusting when xorg.conf vanished and made such a policy, default and empty or config when not default. Yukkie, huge nasty yuk.

He even brings up Android as "good" example. This guy is delusional.

That's until I kept watching, there alot of awful stuff in there.. But some reasonable things as well, some good points.

Last edited by zeebra; 08-20-2019 at 05:08 AM.
 
Old 08-20-2019, 06:33 AM   #317
bifferos
Member
 
Registered: Jul 2009
Posts: 389

Rep: Reputation: 148Reputation: 148
Quote:
Originally Posted by DragoonJ View Post
Back to my previous post, I asked you that if those devices needed an OS, then, why did they needed one? let alone one with systemd.
This is a little OT, but perhaps I can help to answer this. The main reason I see for using an OS it to carry the network stack. Anything that communicates needs a network stack. They are really hard to write correctly, and although there are many commercial offerings they themselves are usually add-ons to an RTOS because it's hard to write a single-threaded one. If you're writing some simple Arduino project, yes you can get away without it the ether packet and application processing is just one big loop. The moment you need to do more than a few tasks it starts to get really hairy and you need some kind of scheduler.

Using a well-known OS like Linux for such a project takes away a lot of risk. The code has been ported to many targets, you have well know development tools (gcc) it will be easier to hire people who know what they're doing. If you've ever configured a Linux kernel and looked at all the networking options, you'll see that you can start with the minimum and just bolt on any additional features with a kernel recompile. You can even go back to one of the supported, older kernels if memory is really tight. You're shipping it in a box so nobody is going to complain.

At the bottom of this page you will see a bzImage 842k in size. This includes an initrd with a Busybox system. It will run in 16MB RAM. You can add a C++ application to that and still fit in 1MB flash. With regards to systemd, I'm sure they will find a way to marry it with Busybox/Buildroot such that it fits in tiny amounts of memory as with the methods I've used in the link above, but I haven't noticed them doing it *yet*.
 
1 members found this post helpful.
Old 08-20-2019, 06:49 AM   #318
fido_dogstoyevsky
Member
 
Registered: Feb 2015
Location: Victoria, Australia
Distribution: Slackware 14.2
Posts: 420
Blog Entries: 2

Rep: Reputation: 498Reputation: 498Reputation: 498Reputation: 498Reputation: 498
Quote:
Originally Posted by jakedp View Post
...Lacrosse is savage and that is the beauty of it. One does not appreciate the skill behind it though until you try to play it.
It is very much a sport for players and not so much for spectators (just like a systemd discussion, to stay on topic).

But (and now I feel like I'm saying "but Slackware really isn't that hard") lacrosse really isn't that rough
 
Old 08-20-2019, 07:01 AM   #319
Lysander666
Senior Member
 
Registered: Apr 2017
Location: The Underearth
Distribution: Ubuntu, Debian, Slackware
Posts: 2,149
Blog Entries: 6

Rep: Reputation: 2431Reputation: 2431Reputation: 2431Reputation: 2431Reputation: 2431Reputation: 2431Reputation: 2431Reputation: 2431Reputation: 2431Reputation: 2431Reputation: 2431
Quote:
Originally Posted by jakedp View Post
I bow to a lacrosse player. Played pond and shimmy hockey later in life (parents wouldn' t pay for hockey when young and it was very expensive when I was young), a year of high school American football (Canadian rules which is not real football), soccer, basketball (boring). Tried lacrosse for a summer and it is more difficult to handle the ball then it looks. Takes some real skill. Had good teachers though and position was drilled into my head.

Lacrosse is savage and that is the beauty of it. One does not appreciate the skill behind it though until you try to play it.
All the girls at school used to play lacrosse in summer while the guys played cricket. It was quite standard. I thought cricket was pretty brutal too.
 
1 members found this post helpful.
Old 08-20-2019, 08:09 AM   #320
rokytnji
LQ Veteran
 
Registered: Mar 2008
Location: Waaaaay out West Texas
Distribution: AntiX 19
Posts: 6,292
Blog Entries: 21

Rep: Reputation: 3152Reputation: 3152Reputation: 3152Reputation: 3152Reputation: 3152Reputation: 3152Reputation: 3152Reputation: 3152Reputation: 3152Reputation: 3152Reputation: 3152
I find it obtrusive when one says buy a better computer when their software won't run on your old POS because you live in the Barrio.

Seems systemd is preferred by enterprise computer centers. The consensus seems to be everything sets up easier across multiple stations.

So I can see how it can be popular because of this.

My beef is I can't adjust it with my limited skill set.
Text files and research I can handle.

Non-editable binary files that default system calls to going to /usr/bin and ignoring /usr/local/bin. I have no use for.
 
4 members found this post helpful.
Old 08-20-2019, 10:19 AM   #321
cynwulf
Senior Member
 
Registered: Apr 2005
Posts: 2,594
Blog Entries: 7

Rep: Reputation: 2064Reputation: 2064Reputation: 2064Reputation: 2064Reputation: 2064Reputation: 2064Reputation: 2064Reputation: 2064Reputation: 2064Reputation: 2064Reputation: 2064
Quote:
Originally Posted by DragoonJ View Post
So yes, it is on that market and is doing very well so FUD like that won't work well here.
It is practically non-existent in the embedded market - and the "embedded market" is actually several markets or sectors all completely diverse to each other - and it has no real presence in any of them.

There are proprietary RTOS which may be on board anything from some kind of fighter aircraft to running something else "mission critical". Then you have various obscure embedded *nix, such as things possibly based on the 'BSDs or whatever else, which you might find on certain firewalls, etc.

There is also the Intel Management Engine, the "out of band" OS within an OS, which is supposedly based on MINIX.

At the lower end there is Linux, running on many more consumer devices, such a SoHo (i.e. domestic router / adsl modem / switch boxes), sat navs and so called "IoT" hardware and much more. Finally there is what is probably one of the most widespread embedded Linux OS - Android. There is also Amazon Kindle and the various streaming boxes you can hook up to your TV to watch youtube or netflix or whatever with.

Practically none of these are running systemd, simply because systemd was not designed for that purpose. That has nothing to do with whether systemd is good/bad or well/poorly designed - it simply doesn't make sense to run something like that in such a scenario (it makes little sense to run sysvinit either).

systemd has been developed around the needs of Linux workstations/servers running something Red Hat (or Debian like) in an enterprise environment.

Last edited by cynwulf; 08-20-2019 at 10:30 AM.
 
2 members found this post helpful.
Old 08-20-2019, 01:23 PM   #322
DragoonJ
LQ Newbie
 
Registered: Aug 2018
Posts: 21

Rep: Reputation: Disabled
Thumbs up

Quote:
Originally Posted by bifferos View Post
This is a little OT, but perhaps I can help to answer this. The main reason I see for using an OS it to carry the network stack. Anything that communicates needs a network stack. They are really hard to write correctly, and although there are many commercial offerings they themselves are usually add-ons to an RTOS because it's hard to write a single-threaded one. If you're writing some simple Arduino project, yes you can get away without it the ether packet and application processing is just one big loop. The moment you need to do more than a few tasks it starts to get really hairy and you need some kind of scheduler.

Using a well-known OS like Linux for such a project takes away a lot of risk. The code has been ported to many targets, you have well know development tools (gcc) it will be easier to hire people who know what they're doing. If you've ever configured a Linux kernel and looked at all the networking options, you'll see that you can start with the minimum and just bolt on any additional features with a kernel recompile. You can even go back to one of the supported, older kernels if memory is really tight. You're shipping it in a box so nobody is going to complain.

At the bottom of this page you will see a bzImage 842k in size. This includes an initrd with a Busybox system. It will run in 16MB RAM. You can add a C++ application to that and still fit in 1MB flash. With regards to systemd, I'm sure they will find a way to marry it with Busybox/Buildroot such that it fits in tiny amounts of memory as with the methods I've used in the link above, but I haven't noticed them doing it *yet*.
Cool answer! I'll take a look closer to it. I would think that for embedded devices or really resource-constrained systems one would use something like NetBSD for the tasks given the massive amount of ports the OS had!

Quote:
Originally Posted by cynwulf View Post
It is practically non-existent in the embedded market - and the "embedded market" is actually several markets or sectors all completely diverse to each other - and it has no real presence in any of them.

There are proprietary RTOS which may be on board anything from some kind of fighter aircraft to running something else "mission critical". Then you have various obscure embedded *nix, such as things possibly based on the 'BSDs or whatever else, which you might find on certain firewalls, etc.

There is also the Intel Management Engine, the "out of band" OS within an OS, which is supposedly based on MINIX.

At the lower end there is Linux, running on many more consumer devices, such a SoHo (i.e. domestic router / adsl modem / switch boxes), sat navs and so called "IoT" hardware and much more. Finally there is what is probably one of the most widespread embedded Linux OS - Android. There is also Amazon Kindle and the various streaming boxes you can hook up to your TV to watch youtube or netflix or whatever with.

Practically none of these are running systemd, simply because systemd was not designed for that purpose. That has nothing to do with whether systemd is good/bad or well/poorly designed - it simply doesn't make sense to run something like that in such a scenario (it makes little sense to run sysvinit either).

systemd has been developed around the needs of Linux workstations/servers running something Red Hat (or Debian like) in an enterprise environment.
I meant that originally with RPi systems (that now that I think about it, they are more of a desktop or server, or whatever purpose they might have) but thank you,thank you! that is really the kind of answer I was looking for. Yes, indeed, systemd was originally developed by RedHat for their enterprise customers, I heard the initial design of the software was going around the concept of desktop-based systems, it seemed like Lennart originally wanted systemd because he wanted something better for a desktop experience but his bosses told him to add server or workstation features, which he begrudgingly did. This is just a rumour going around though.

As for mission critical systems, well, I only recall ATMs running with some pretty old version of Unix still. There were a few I saw that included some version of Windows XP in their offerings but those were far and in between, it seemed like Unix was the most common one in those devices. Then again, they rarely change the systems around ATMs for some reason. Probably due to familiarity
 
Old 08-20-2019, 01:40 PM   #323
ttk
Member
 
Registered: May 2012
Location: Sebastopol, CA
Distribution: Slackware64
Posts: 965
Blog Entries: 27

Rep: Reputation: 1354Reputation: 1354Reputation: 1354Reputation: 1354Reputation: 1354Reputation: 1354Reputation: 1354Reputation: 1354Reputation: 1354Reputation: 1354
Quote:
Originally Posted by automaticjerk View Post
What did systemd get right? And how could we improve BSD init based on that?
The key thing systemd got right is that it's more accessible and understandable to people.

Almost everything people claim systemd can do that traditional systems "cannot", traditional systems can actually do. It's just that few people know how, and learning how to do it is so much of a chore that people assume it's impossible. A typical example of this is monitoring all of a process' subprocesses, which leaves people scratching their heads if nobody explains to them the somewhat inverted logic of the PPID attribute, but which systemd makes easy (by handling the PPID logic so the user doesn't have to).

That suggests to me that the traditional Linux ecosystem suffers from a degree of opacity and non-intuitiveness too high for most people to follow, and they'd rather have something "good enough" take care of it for them, even if learning how to use the system themselves would bring them more power and flexibility. And make no mistake about it, if one's system more or less resembles Lennart's laptop, then systemd's assumptions will make sense, and it will seem to JFW (barring bugs and security vulns). A lot of people like that.

How to incorporate this lesson into traditional Linux? A few things occur to me:
  • Documentation -- If we provide documentation showing how to do all the things people want to do with their systems, it might lower the bar of entry a bit.

    This isn't a slam-dunk, though, since there is already documentation of which users refuse to avail themselves, and it doesn't help with experts who are already familiar with the system but need to develop nontrivial solutions (like the GNOME devs who welcome systemd-logind so they don't have to write it themselves).
    .
  • Mentorship -- Over the years, more senior computer users took me under their wing and taught me how to do things, and the better ones taught me why doing it that way was important. I have noticed that today there is a dearth of experienced users willing to pass their hard-earned expertise along to the next generation of users (though social concentrators like LinuxQuestions definitely help).

    Perhaps if people got more involved with their local LUG (and created one if there is none) and actively recruited members, it would help foment apprenticeship, shine some light into Linux's darker recesses, and give new users a taste of the power that comes from deep knowledge.
    .
  • Automation -- There are always going to be people who want the system to JFW without having to learn esoterica, and that implies the need for automation that does all the things the user would do if they knew how. Systemd solves this problem by incorporating a dozen or so different traditional system utilities and taking over their functions, but it is also possible to write equivalent automation which interfaces with those traditional utilities and tries to do the right thing.

    Many years ago I wrote a script called "unixadminbot" which automated many datacenter tasks normally performed by junior sysadmins, and more recently "configuration management systems" like Chef and Puppet have seen similar use (though they still lack some of unixadminbot's functionality, like diagnosing and rectifying problems which pop up in monitoring). Writing unixadminbot taught me that interfacing with the Linux ecosystem that way can be tricky, but is quite practical, at least for the niche unixadminbot occupied (making sure directories have the right permissions, sanity-checking fstab, making sure the right services are running, killing misbehaving processes before OOM-killer steps in, etc).

    Systemd occupies a rather different niche, but is still at the core of it automation with a dbus-facing API. It seems to me we should be able to develop something similar, which the user can choose to use or not, which uses the traditional Linux ecosystem rather than subsuming it.

Unfortunately none of these are a recipe for success for competing against systemd, because systemd has mainly been successful by dint of weaponizing software dependencies, not by dint of its utility. Unless one wants to play dirty pool, any such competition will be lopsided (and more lopsided if the systemd devs succeed in making systemd a dependency of the kernel, a front where they have fortunately not yet gained a toehold).

Last edited by ttk; 08-20-2019 at 01:54 PM.
 
5 members found this post helpful.
Old 08-20-2019, 03:18 PM   #324
automaticjerk
LQ Newbie
 
Registered: Apr 2015
Distribution: Slackware
Posts: 17

Rep: Reputation: Disabled
Quote:
Originally Posted by ttk View Post
Many years ago I wrote a script called "unixadminbot" which automated many datacenter tasks normally performed by junior sysadmins, and more recently "configuration management systems" like Chef and Puppet have seen similar use (though they still lack some of unixadminbot's functionality, like diagnosing and rectifying problems which pop up in monitoring). Writing unixadminbot taught me that interfacing with the Linux ecosystem that way can be tricky, but is quite practical, at least for the niche unixadminbot occupied (making sure directories have the right permissions, sanity-checking fstab, making sure the right services are running, killing misbehaving processes before OOM-killer steps in, etc).

Systemd occupies a rather different niche, but is still at the core of it automation with a dbus-facing API. It seems to me we should be able to develop something similar, which the user can choose to use or not, which uses the traditional Linux ecosystem rather than subsuming it.
Am I wrong, or is systemd creeping into this particular niche as well? For all I know, it has already. This script of yours sounds like it might be useful on the desktop as well as the datacenter, though. Is it out in the world for us to peruse?
 
Old 08-20-2019, 03:52 PM   #325
ttk
Member
 
Registered: May 2012
Location: Sebastopol, CA
Distribution: Slackware64
Posts: 965
Blog Entries: 27

Rep: Reputation: 1354Reputation: 1354Reputation: 1354Reputation: 1354Reputation: 1354Reputation: 1354Reputation: 1354Reputation: 1354Reputation: 1354Reputation: 1354
Quote:
Originally Posted by automaticjerk View Post
Am I wrong, or is systemd creeping into this particular niche as well? For all I know, it has already.
There is some overlap between systemd and CMS, and also some overlap between systemd and unixadminbot (specifically, bringing up services, though unixadminbot was more reactive than proactive). I don't think it's looking to replace all the functionality of Puppet or Chef, though. Relatedly, the CoreOS orchestration tools integrate with systemd -- when I wanted to try etcd on Slackware, I had to remove some of systemd's hooks from it (logging and socket activation).

Quote:
This script of yours sounds like it might be useful on the desktop as well as the datacenter, though. Is it out in the world for us to peruse?
It is the intellectual property of The Internet Archive, which I don't think is even using it anymore. I've been meaning for a while to cleanhouse-reimplement it, generalize it a bit, integrate it with my whackamole security countermeasures script, and publish it as an open project. If that happens any time soon I'll post about it here.
 
1 members found this post helpful.
Old 08-20-2019, 04:06 PM   #326
enorbet
Senior Member
 
Registered: Jun 2003
Location: Virginia
Distribution: Slackware = Main OpSys
Posts: 3,514

Original Poster
Rep: Reputation: 3404Reputation: 3404Reputation: 3404Reputation: 3404Reputation: 3404Reputation: 3404Reputation: 3404Reputation: 3404Reputation: 3404Reputation: 3404Reputation: 3404
Quote:
Originally Posted by Lysander666 View Post
All the girls at school used to play lacrosse in summer while the guys played cricket. It was quite standard. I thought cricket was pretty brutal too.
While this is WAY OT, I can't help myself because I love everything about Lacrosse. I was shocked when girls began to play it in schools since it was so rough partly due to being allowed to hit (check) with (what in my day were hardwood, now aluminum or fibre) sticks but largely due to the insane mass of the ball and the extreme velocities they can reach with the massive mechanical advantage of the long lever of the sticks. We used to practice with a goal outline on a brick wall with rotating lines of "attackers" and one time I threw at the "goal" and the guy following me missed an odd hop and was hit in the chest. A half hour later he was spitting blood.

Perhaps the reduced upper body strength in females is why it isn't viewed as overly dangerous for girls... still seems odd to me. IIRC the Iroquois Nation of native american tribes invented Lacrosse as an alternative to War, but then the field was miles long and the "balls" were rocks.
 
3 members found this post helpful.
Old 08-20-2019, 04:16 PM   #327
enorbet
Senior Member
 
Registered: Jun 2003
Location: Virginia
Distribution: Slackware = Main OpSys
Posts: 3,514

Original Poster
Rep: Reputation: 3404Reputation: 3404Reputation: 3404Reputation: 3404Reputation: 3404Reputation: 3404Reputation: 3404Reputation: 3404Reputation: 3404Reputation: 3404Reputation: 3404
I would like to know more about the assertion that systemd is easier for newcomers to comprehend than text scripts such as proposed by ttk. Not only does human readable text seem far more intuitive but in this case we are talking also about the difference between parallel and serial. As I recall, the very reason we have Linux (possibly at all) ios because RMS was bogged down with the vastly more complicated and parallel microkernel while Linus opted for the much easier to debug, serial macro kernel. Is this not so? and by extension, isn't systemd far harder to debug (but also possibly more efficient, ultimately) than serial init?
 
Old 08-20-2019, 04:49 PM   #328
ttk
Member
 
Registered: May 2012
Location: Sebastopol, CA
Distribution: Slackware64
Posts: 965
Blog Entries: 27

Rep: Reputation: 1354Reputation: 1354Reputation: 1354Reputation: 1354Reputation: 1354Reputation: 1354Reputation: 1354Reputation: 1354Reputation: 1354Reputation: 1354
Quote:
Originally Posted by enorbet View Post
I would like to know more about the assertion that systemd is easier for newcomers to comprehend than text scripts such as proposed by ttk. Not only does human readable text seem far more intuitive but in this case we are talking also about the difference between parallel and serial.
It's easier for most users because in many cases they don't have to do anything.

When a user does want to tinker with the system, they need only learn what behavior systemd exhibits, and work within the confines of that behavior. To many people this is easier than the process of deciding for themselves precisely the behavior they want to see, and writing a shell script to make it happen.

It's analogous to the difference between answering questions and writing an essay. Most people find it easier to make a response than to come up with a topic to write about and turn a blank piece of paper into prose. So also do many people find it easier to modify systemd's behavior via parameters.

Quote:
isn't systemd far harder to debug (but also possibly more efficient, ultimately) than serial init?
It's one of those things that's hard to debug, but for common use-cases doesn't usually need to get debugged.

Last week one of my coworkers was temporarily blocked on his project by a unit file bug which took him a couple of days to figure out. That's about a thousand dollars worth of productivity lost to a problem which likely would have been trivial to fix in a shell script. He's a smart guy, so if he had problems debugging it, I expect most people would have too.

BUT we develop and use a lot of proprietary services, here. We have to write our own unit files for them all, and some of the dependencies can get a bit convoluted. The typical user will only be using services whose unit files have already been written and debugged by upstream, so as long as they don't step away from the road less traveled they should rarely experience any such trouble.

To put it another way, the more a user's use-case adheres to systemd's expected use-cases, the more systemd will appear to JFW.

Because of this, it is not surprising that so many users have stated in this discussion that systemd works just fine for them. Barring a bug or security vulnerability, it will work just fine for a lot of people.

Okay, I've prattled enough here. I'm going to try leaving it alone for the rest of the week.
 
9 members found this post helpful.
Old 08-20-2019, 04:56 PM   #329
bifferos
Member
 
Registered: Jul 2009
Posts: 389

Rep: Reputation: 148Reputation: 148
Quote:
Originally Posted by DragoonJ View Post
Cool answer! I'll take a look closer to it. I would think that for embedded devices or really resource-constrained systems one would use something like NetBSD for the tasks given the massive amount of ports the OS had!
Yes, NetBSD has a lot of ports but supports a fraction of the devices Linux does. Trying to get it up and running on a new platform felt like it was a decade or more behind Linux. The NetBSD people like to quote how many platforms they support, but if you combine the generic (Torvalds) kernel with all the OpenWrt platform-related patches and take the sum total of that, I believe it surpasses what NetBSD supports.

I admit it was a while back that I was NetBSD hacking, but they didn't even have curses-based kernel config you had to edit some config files. Compared with the Linux kernel build system that tracks dependencies has interactive menus and includes help text for most of the options NetBSD was like the dark ages.
 
2 members found this post helpful.
Old 08-22-2019, 11:12 PM   #330
Richard Cranium
Senior Member
 
Registered: Apr 2009
Location: Carrollton, Texas
Distribution: Slackware64 14.2
Posts: 3,748

Rep: Reputation: 2085Reputation: 2085Reputation: 2085Reputation: 2085Reputation: 2085Reputation: 2085Reputation: 2085Reputation: 2085Reputation: 2085Reputation: 2085Reputation: 2085
Quote:
Originally Posted by ttk View Post
Many years ago I wrote a script called "unixadminbot" which automated many datacenter tasks normally performed by junior sysadmins, and more recently "configuration management systems" like Chef and Puppet have seen similar use (though they still lack some of unixadminbot's functionality, like diagnosing and rectifying problems which pop up in monitoring).
The main thing that scared me about Chef is that it was apparently better than what was already in use (this is a 2015 observation).

I've done OO programming since 1995 and thought Chef was insane; that might be because the OO paradigm isn't useful in instantiating server objects, but I find that risible. A lot of DevOps folks swear by Chef versus at it.
 
2 members found this post helpful.
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
LXer: Q. Can your Linux PC run Crysis? OK, it can. But will it run natively? A. Soon, very soon LXer Syndicated Linux News 0 03-11-2014 11:01 PM
LXer: My Nerd Life: Too Loud, Too Funny, Too Smart, Too Fat LXer Syndicated Linux News 0 01-24-2014 05:21 AM
LXer: Abolishing patents: Too soon or too late? LXer Syndicated Linux News 0 01-09-2013 02:20 PM
Application Assessment for Linux Migration MSquared Linux - Software 1 02-02-2005 05:14 PM
Probed and Attacked - Battle Damage Assessment halifax Linux - Security 2 08-17-2003 08:06 PM

LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware

All times are GMT -5. The time now is 10:09 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration