User talk:Hlangos

Wow, somebody made my a sysop?? :-) Thanks... I'll try not to screw up everything (at once).

---

Thanks for the clarification about Tai Hui.

No worries. It was my fault.

I thought I'd also say a quick hello as I've noticed that the bulk of edits seem to be by you, CityK and I.

Might seem so but I mostly mucked around with pages that are not yet widely linked.

I thought I'd also take this opportunity to ask what you think about the current state of the wiki in general and whether you think there are areas that could do with some attention.

I havn't seen a lot of the wiki yet. So my view might be a little biased. Mostly I think the wiki grew without a lot of structure and then the merge made a mess of the structures that began to appear. That's why I really appreciate the work you've done by categorizing hundreds of pages. Also adding all those links should help people who want to contribute their knowledge to add it in one place without lots of duplicate entries that are impossible to keep up to date.

CityK advised me that some sort of graphics for stubs etc. would be useful. I'm still mulling this over as I don't really trust my graphics skills. My girlfriend's an artist, so I'll ask her what she thinks.

I am not much of a graphics person neither.

either am I :P ... Jim, don't worry -- it was just a suggestion (for some additional eye candy), but if its not for you, then its not for you. I don't want anyone to feel obliged in any way --CityK 05:55, 31 May 2009 (CEST)

It occurred to me that several chipset and device manufacturers have either been bought out, gone out of business or been rebranded. I think it would be useful if the relevant pages (Chipset vendors, DVB-T PCI Devices, etc.) reflected this but I really wanted a second opinion before I start changing things. The chipset vendor page is probably the most straightforward to change because of its length and the fact that the users of this page will probably have at least some technical knowledge.

I'd say go ahead. If you are unsure about the changes, put a mockup/sample on the associated talk page and send me the link.

Users of the wiki can be split into three broad categories:

1. Users looking for buying advice.
2. Users looking for a way to make their existing devices work in Linux.
3. Developers looking for any relevant info they might need for driver/application development.

I reordered them in (what I think) is the order of the depth of detail they seek. The first ones need low detail but on lots of devices. The second group needs more detail on one or very few devices. The last one needs lots of details.

So, I pose the following question: Could the wiki take account of these user-types more elegantly? I certainly think that the information regarding the exact nature of support available in Linux could do with some distillation. http://hardware4linux.info/ uses a five-step rating system from unsupported to fully supported. Could we implement something similar? I can see that the task of standardizing the wiki is not a small one, but it'll be much easier if there's a systematic approach. I'd certainly value any input from you.

I am all for standards. I've put some time into standardizing and concentrating the information about USB DVB-T Devices here. and I hope there is a way to extend the approach to other parts of the wiki too. As you pointed out the users are a diverse bunch and they come with different needs. In order to serve them all we need to have some way of filtering/tagging the information. So that we can show different degrees of detail to different users (or on different pages) without duplicating all the data.

Cheers -henrik

Hi Henrik, sorry for taking so long on getting back to you on that. I asked Krufky twice on irc about the database idea and given that he never answered in either case, I will surmise that he choose to ignore the questions. In light of that fact, and combined with the fact that my own time is becoming increasingly constrained by work and other areas of personal interest, I don't want to hold anyone else up -- meaning, if you believe that you can make meaningful improvements (and it certainly looked like you were moving in that direction) then please proceed. Further, to this point, as I am an ATSC/NTSC user, it would certainly make more sense that someone who is a DVB-T user manage the DVB-T info.

Anyway, as both of you (Jim/Henrik) should know by now, standardizing the wiki is, indeed, no easy task ... nor integrating the duplicated content of the former V4L and DVB wikis, or making (where appropriate) articles agnostic between the two different subsystems -- lots of work in those areas is still required. However, I believe that eventually a nice standardized and unified wiki is achievable -- and one that is easier to manage if we can leverage efficiencies. --CityK 05:55, 31 May 2009 (CEST)

Hi CityK, I've checked Special:Version and it seems somebody updated to MW 1.14. Great! Now I only need the Extensions ParserFunctions and StringFunctions. If I have those I can do row selection by e.g. manufacturer, chipset, you name it. --Hlangos 22:51, 1 June 2009 (UTC)

Hi Henrik -- J.S updated the software. Weren't those extensions included (I thought you had mentioned that they were in 1.14)? If they aren't, just fire a message off to J.S asking to enable them.

On another thought/tangent -- Jim set up a new page recently, and its talk page might be a good message center for all of us, so that we don't start cross posting on each other across different articles etc. ... Talk soon. --CityK 03:51, 2 June 2009 (UTC)

Hi CityK, I agree that posting around on talk pages is not the best place for that kind of discussion. In fact I think wikis are not very useful for discussions at all. Talk articles tend to lose cohesion realy fast and for somebody new they are an ugly read. Also any wiki article should be cleaned up from time to time and if you do that to a discussion how do you decide which part is worth keeping? Especially when you didn't agree about something, deleting somebody else's contribution can send the wrong signal. Mailinglists are way better for this because you can pick the part of a posting that you want to reply to and ignore the rest. Also they don't need any cleanup. --Hlangos 09:01, 3 June 2009 (UTC)

Agree all around --CityK 01:13, 5 June 2009 (UTC)

Further ramblings...

Hi again Henrik,

I forgot to mention in my previous post on CityK's page that I fully support your idea for a database. I've created a few data-driven sites and it seems obvious to me that this is the way to go. The database schema would be quite simple and reflect the ideas that we're all talking about. In addition, I'm fairly sure that JavaScript and HTML forms and the like can be embedded in wiki pages. I think a search option in addition to the text box that is currently employed would be easy for users to operate and take them to the place they need as quickly as possible. I've looked into the possibility of hosting an external database in the event that the LinuxTV.org hosting won't tolerate any more databases (we only need one!!!), so let me know what you think. In any case, I'm going to try to get in touch with Krufky and Mauro and see what they think about my proposals.

These user pages are rubbish for one on one communication!!! If there was a secure way to send you my email across the wiki, I would. If you think of one, let me know.

Cheers

Jim

If you use the link in the toolbox to send email to the user when you are in their user page or user discusion page you can send him/her a e-mail and only he/she will know your mail. howl 13:12, 12 June 2009 (UTC)

To see that link the in the toolbox, the person needs to leave an email address and to activate this feature using "my preferences". On my user page it should be active.

• I've just looked at your page and there is no change to my toolbox.

I don't see the E-mail this user feature on your page neither. Please check your preferences and make sure you have an authenticated email address there, and the email feature is activated.

About the database idea. I like the thought but I am afraid it is what in German you'd call "Shooting sparrows with canons." Too big and unwieldy a tool for too small and agile a target.

• We have a similar saying: 'using a sledgehammer to crack a nut'. I take your point though!!

You have to keep in mind that it will be a rather static database as less than a hand full of devices will be added in a month while the technology is in slow but constant flux and new formats/interfaces will be two to three a year? What I want to express is that the amount of change in the data is rather small in relation to the amount of structural change. IMHO a database makes sense where that ratio is in the order of at least 10000:1. Somebody will have to update the lists of formats and interfaces over years. So you'd either have to design your database system so flexible that new values for fields can be added by users and maybe even new fields. Or you'll have to adjust your database constantly. And "you" really means YOU. As nobody else will find the time to read up on where the database is stored, who has access, how things are done and so on... The learning curve is way to steep for the casual user who only wanted to add some data on a card with the new wireless USB4 interface or support for the new MPEG17 format.

• I agree about the slow rate of change in the data relating to new devices and technologies. However, the key part of the idea is that it is tied in with the state of feature-support. This changes daily and it is my intention to help the users AND developers acquire/input the necessary information that they have/need. I think that the slow rate of change in new technologies is a good thing with regard to the database. It means only a single table/field needs to be updated as technologies evolve, which should make it easier for whoever is updating it. There is a testing database under development (finished but not published) at the moment and it's my intention to use some of its infrastructure if I can. I received the source for it this morning.

The main point is that the structural data is in a constant change. And in relation to the device data it is changing rather fast. And it needs to be changable by the user if you don't want to be tied to the project for the rest of your life.

While keeping the whole thing in the wiki results in a less flexible solution, as you can't do all the nifty sql queries and joins, I think in the long run it is the more sustainable solution. You have to think about what will happen to the code once you decide that watching TV is a terrible waste of time. (I once did and I didn't own a TV for almost 10 years.) Who will be able to continue your work? And what happens if the project moves to a different hoster, platform, whatever ... A wiki-contained solution will always be more portable. And if you put your data in a Database you probably lose the history/undo functionality that the wiki gives you for free. (Think about the effect of a single stupid bored kid.) I'm sorry if I sound negative but I think a database is too much infrastructure for too little data. --Hlangos 21:46, 17 June 2009 (UTC)

• The inflexibility of the wiki format is precisely the thing I'm trying to address. I don't agree that a DB is necessarily less portable. Mediawiki has a php/MySQL backend, so anywhere the wiki can go, another similarly-designed DB can go. Logging changes is also no big deal for the same reason. I do think that the risk of data corruption from the bored and stupid is an issue and will endeavour to address it, but with a suitable logging system, I don't see why it should be any more complex than the diff/hist method used by the wiki.

Took me a while to get back to this point (time wise (had to do a lot of other things first) and stream-of-thought wise (discussions on wikipages are horribly difficult to read. even if you take part in them.)). Let me quickly answer the last points.

• Portability: It is easy enough to set up a new home for a mediawiki and there are (or ought to be?) all kinds of migration guides. None of this exists for the device database. The amount of (very dull) documentation work is hard to over estimate. Let me give you an example: At work I usually set up new infrastructure three times. First to see how it is done. The second time I document the process step by step and also the reasoning behind the decisions that I had to make along the way. The third time is the quickest as I follow blindly my own documentation to see if it gets me to the same result. This is a lot of work that you should include in your calculation. Also setting up the database for mediawiki is for the most part automated in installation scripts and distribution packages. So the knowledge of how to setup databases within your dbms, how to create users, grant rights, etc. is not part of the average wiki maintainers active vocabulary anymore.
• The diff/hist functionality within media is nice and reasonably straight forward as long as you stay within a domain, lets say within the history of an article. As soon as you make changes to remotely structural elements, you run into situation where data gets lost or where it gets hard to recover from a change or hard to follow the history. Example: Rolling back changes to a comment is easy. Rolling back the changes if somebody messed up the comment column definition of your database is hard. Even more so if other users made changes afterwards to records that use those definitions.

Thanks so much for your comments Henrik. I'm still set on the database idea, but you've given me some issues to consider. As always, your highly rational perspective is of great help. I hope it's ok to continue to run ideas past you, even if we are not in total agreement about the way to proceed. We do, however, agree that the quality of data (wherever it's stored) is extremely important. If you have any further thoughts about this model, please let me know.

Cheers Jim

I guess our different views don't collide as much as I thought in the beginning. In fact my work can be translated into your database later on. So I will continue to translate and gather the scattered information and maybe one day that will be the seeding data for your database. Cheers -henrik

Sign with local timezone

Hi Hlangos, I'm trying to sign with my local timezone but I can't. I have set mine in preferences but it doesn't work. How do you do?

I think it is a server setting rather than a user setting. Probably changed when the mediawiki was last updated. Personally I prefer UTC because it makes it easier to compute relative edit times. (Ok, I only have one or two hours of difference to compensate to my local tz, so it is a lot easier for me than for somebody from the west coast or from nz.) --Hlangos 09:47, 1 October 2009 (UTC)

I have +2 too, but sometimes +1, certainly a real mess xD, let's go with UTC then --howl 12:33, 1 October 2009 (UTC)

Sundtek

Hi Hlangos, actually what I noticed when adding Sundtek to this wiki is google did not pick up any site from this wiki? Maybe the Wiki is hosting some search engine blocker entries, or maybe I might be wrong? As from our side we did not notice anyone coming from Linuxtv actually anyway MarkusR 11:55, 12 October 2009 (UTC)