User talk:M86/Archive 1

Wikidevi {data-download | mirroring | git-like tracking }
Hello, first of all great work with the semantic-web support.

We're running a local mesh community and would like to add a few community-specific template fields, dedicated semantic-queries, etc, but otherwise serve 99% identical wikidevi data. This will also enable us to offload automatic tool queries from wikidevi to our servers. How to separate our overlaid-data from what we pull from wikidevi is not a trivial issue, but the first step is to be able to periodically 'pull' on wikidevi edits. Ideally we would like to enable editing only for local data, and direct users towards doing all other edits on wikidevi - whether this is technically possible or not, it is our intention - at worst case we would simply overwrite wikidevi data changes at the next data pull.

It would be extremely helpful if you could setup an rsync [*] read-only server to enable syncing with periodic wikidevi database dumps. Rsync works well with large binary files so simply synchronizing with whatever DB dump format would work.

Thanks!

[*] http://en.wikipedia.org/wiki/Rsync


 * The raw DB is not going to be made publicly available..
 * One time exports of wiki data can be done via Special:Export (easy to re-import) or with Data Transfer.
 * Long term data syncing may be best served by using the MediaWiki API. This is GeneWiki+'s approach, and it seems to work well for them. Their software appears to be available here.
 * --M86 (talk) 22:53, 8 February 2013 (EST)
 * daily exported wiki-text is now also available here, btw
 * --M86 (talk) 12:00, 6 March 2013 (EST)
 * daily exported wiki-text link doesn't work (404). Why not provide DB dump? It could be archived at archive.org like wikipedia.
 * X64 (talk) 01:54, 10 December 2013 (EST)
 * The URL changed - see my user page.
 * Noting again: The XML dump contains everything that would be needed to replicate all content on here (+ all previous page history w/ the full dump), aside from images. Most wikis backed up via archive.org are backed up via their XML dumps .. it's easiest for a third party (or non) via the MW API / Special:Export
 * There would not be much (if any) additional value provided by a raw DB dump that would not be provided with the XML dump.
 * M86 (talk) 03:42, 10 December 2013 (EST)

Pushing properties from table to multiple pages
What is the simplest/easiest way to add the properties first_support_kernel_version and first_support_kernel_date to all the adapters linked in: User:X64/Linux_mainline_kernel_wireless_device_support ? Note: the page is auto-generated from Linux kernel mainline repository.
 * The easiest way? Well, with what you have on the page, it would probably be easiest to...
 * convert each table row to a subobject or assign each property to the same subobject individually, per column
 * convert the table display to a query of all subobjects on the page if necessary
 * from some template called from the main device / infobox template, query for info (if available) and go from there
 * .. but it would probably be worth noting..
 * obviously, device ID addition does not necessarily indicate proper support (rt3572 devices come to mind)
 * aside from the device ID, chipset support may have already been existent
 * --M86 (talk) 11:13, 2 November 2013 (EDT)
 * True, it's not perfect. It's still useful when shopping around for WiFi adapter with out-of-the-box mainline kernel support, or checking out kernel support for the latest 802.11ac/ad adapters. Only /drivers/net/wireless drivers are included, not /drivers/staging (for now). Some work remains to be done with PCI subvendor/subdevice IDs.X64 (talk) 12:06, 2 November 2013 (EDT)
 * Could you build a small example property table and associated template on this wiki that I can use? I barely got the WA ID query link template working, the template language is not very user friendly...
 * I'm in the process of adding PCMCIA. On linux kernel,
 * some cards are identified by: manf_id:card_id (1234:5678),
 * some cards are identified by prod_id (12345678),
 * some by a prod_id pair (12345678:23456789), and
 * some by a prod_id triple (12345678:23456789:3456789a).
 * What are the corresponding property names you use for PCMCIA IDs?
 * timeout error? below a certain row, User:X64/Linux_mainline_kernel_wireless_device_support shows the message Template:WA ID query link instead of the running the template.
 * (note: added new wireless adapters for kernel 3.12)
 * --X64 (talk) 17:21, 7 November 2013 (EST)
 * It should be relatively straightforward (though, yes MediaWiki syntax is an abomination) - just add something sort of like


 * for each entry in the table. An example of something like that in use would be here (for this table).
 * PCMCIA devices are not handled especially well - numeric IDs are recorded with the same 'Vendor ID' and 'Device ID' properties used by other devices, device strings are (currently not available for much of anything) currently being thrown in the 'Device_identification_string' property
 * Reg. the error, that page was hitting the maximum page size after template expansion - it should be resolved with the page as it is.
 * --M86 (talk) 20:57, 7 November 2013 (EST)


 * Update:
 * I made the table with subobjects: see: User:X64/Linux_kernel_wireless_device_support
 * Can you change main device / infobox template to link to this info? For example, the infobox for TP-LINK_TL-WN727N_v3 USB ID 148f:5370 would have: "first seen in Linux kernel v3.00 on 2011-07-22", according to the table data. There are 8 additional devices with the same USB ID.
 * Do you have lua-template module installed? It allows saner template scripting:
 * Simple example (creating text using string concat):
 * Complex example (creating text using HtmlBuilder):
 * It has been deployed and running on wikipedia for more than half a year.
 * As mush as I like cats and dogs, is it possible to skip this? There are some trick pictures with cat+dog together :)
 * -- X64 (talk) 09:35, 23 November 2013 (EST)

noted --M86 (talk) 10:18, 23 November 2013 (EST)
 * yes, will do so in some fashion later
 * Scribunto is installed, so yes, Lua scripting should be enabled and working.. but I think Semantic MediaWiki support is still a WIP. for anything that doesn't need SMW specific features, it should / may work fine
 * the ASIRRA widget shouldn't show up for users that passsed e-mail verification - I added you to the 'emailconfirmed' group so it may stop (let me know if it doesn't)

Nice! --X64 (talk) 17:09, 25 November 2013 (EST)
 * I added some missing Realtek IDs (ex: PCI 10ec:8176), but the data doesn't seem to propagate to the respective pages, such as Encore ENEWI-1XN42. That page still shows: PCI ID not yet observed in any mainline kernel / this list.
 * Is it possible to modify Template:WA ID query link to show a link to the actual device when device_count == 1? (instead of a link to a query result table containing a single entry). ie:
 * instead of this: switch (count) 0 = blank; default = show link to query
 * do this: switch (count) 0 = blank; 1 = show direct link to device, default = show link to query
 * I don't know how to make the "show direct link to device" part...

Some pages may need to be refreshed manually to wipe the cached page - hitting the 'Refresh' tab (in the down arrow menu next to the search box) would be a good idea --M86 (talk) 23:53, 25 November 2013 (EST)
 * Would changing the 'WA ID query link' link for single-device queries really be preferable? It would make it a bit less consistent if some pages did not direct to query links..
 * .. but, yes, it would obviously be relatively simple to change it over to link directly to the device page

--X64 (talk) 10:50, 29 November 2013 (EST)
 * I created the 'WA ID query link' template specifically for User:X64/Linux_kernel_wireless_device_support, no other wiki pages use it (it based on 'WD WA USB query link2'). Since the large majority of queries in the device table link to a single device, it would make sense to link to the device directly in that case.
 * Some pages are still not refreshing correctly, for example: D-Link_DWA-160_rev_B2, despite clicking the wiki 'refresh' option.

|1 Device --M86 (talk) 15:10, 29 November 2013 (EST)
 * Perhaps, but the layout of the pages would still differ from the other links w/ >1 ID. .. not that I'm against changing it, but I don't really see it as necessary
 * .. that being said, it would be simple to add - just query for the number of devices using the ID (already done for the query link) using the 'count' result format and display something like the following for those w/ 1 device
 * The device table page itself may have needed to be refreshed for some reason - it seems to be working now

I'd like to move User:X64/Linux kernel wireless device support out of my user page to the main wiki. It requires renaming/moving several pages. I was thinking: X64 (talk) 18:39, 27 February 2014 (EST)
 * "User:X64/Linux kernel wireless device support" to "List of Wi-Fi Device IDs in Linux" (the main page)
 * "User:X64/Linux Wi-Fi device entries" to "Linux Wi-Fi device entries (include only, auto-generated list)
 * "User:X64/Linux kernel wireless device support entry" to "Linux Wi-Fi device entry" (include only)
 * There are also "X64/DevID_table/Bus", "X64/DevID_table/VID" etc (in device entry). I don't know if/how to rename them. Suggestions?
 * (assume there are going to be additional pages "List of X Device IDs in Linux" some day, X=Bluetooth, etc)

I'm fine with that. But.. --M86 (talk) 19:07, 27 February 2014 (EST)
 * The entry page should be moved to the Template namespace.
 * The transclude of the device entries page needs to include a colon at the beginning of the page name if it's being moved to the main namespace
 * I can bulk rename/move the properties, if needed or desired (X64/DevID_table -> Linux_DevID_table, maybe?)
 * I can bulk rename/move everything else, too
 * Maybe it's be better if you do the renames as you see fit, and I'll regenerate the auto-generated part. What should appear exactly in the "entries" page instead of "User:X64/Linux kernel wireless device support entry|USB_2019_ab29|..." ?
 * I was referring only to the   line on the 'device support' page, not a major issue --M86 (talk) 19:27, 27 February 2014 (EST)
 * .. and, to note, I'll move it in a bit (1-2 hrs) provided there are no additional issues. I will likely change everything all at once (including the automatically updated pages)
 * --M86 (talk) 22:55, 27 February 2014 (EST)

I'm keeping the redirect from User:X64/Linux_kernel_wireless_device_support, but I would like to delete the include-only sub-pages instead of redirecting to another template (not safe). I can't seem to be able to delete these sub-pages:
 * User:X64/Linux kernel wireless device support entry
 * User:X64/Linux_Wi-Fi_device_entries
 * done
 * Also, what is the meaning of the ':' prefix in ":Linux Wi-Fi device entries" page name?
 * The colon is necessary to transclude a page in the main name space
 * Is there reason not to rename X64/DevID_table/VID property to just "VID" ?
 * I did not bother renaming the properties at all, yet - keeping a prefix would be preferred to indicate they will be used with various device ID table pages, not device pages
 * Keep kernel version as is ("v3.9") or add 0's to maintain lexicographic order ("v3.09") as I did before? Without the zeros, any table using kernel version such as this table is not sorted correctly by version... What do you think? X64 (talk) 15:13, 1 March 2014 (EST)
 * As is should be fine - that particular table could simply reformat the kernel version.. or an ISO formatted kernel release date could be added to another column --M86 (talk) 17:21, 1 March 2014 (EST)

https problems
Wikidevi HTTPS certificate seems to be self-signed, with SHA-256 fingerprint: 16 DC 2B 1E B9 DD DE E5 1C D6 C2 F7 FD 81 A2 58 EC D9 E9 38 BC 04 BA 7F 5E DD C5 AA 17 4B 3F DE - is that by design?

Also, editing doesn't seem to work in https ('save page' doesn't save the page, maybe a captcha problem?)
 * Yes, the server is intentionally using a self-signed cert (that is the one..) at the moment. Not sure why the captcha would not be working in that instance.. I'll look into it. The Asirra script was being loaded via http - it should work now.
 * --M86 (talk) 15:57, 22 November 2013 (EST)


 * https://wikidevi.com/ (secure https) redirects to http://wikidevi.com/wiki/Main_Page (non-secure http)
 * Browsing on any page on secure site gives warning in chrome: The page at https://wikidevi.com/wiki/Main_Page displayed insecure content from http://wikidevi.com/w/skins/Monitored_by_WikiApiary.png.
 * It should / may be resolved now..
 * --M86 (talk) 18:46, 5 December 2013 (EST)

With NoScript enabled, I see a mixed contents warning from the piwik image. I suggest to drop "http:" such that the protocol is automatically detected: 
 * --Lekensteyn (talk) 05:42, 15 March 2014 (EDT)

FCC Approval dates
Why do some show, like Buffalo WZR-1750DHP, and some not, like Belkin F5D8635-4 v2?
 * --DarkShadow (talk) 19:30, 8 December 2013 (EST)
 * db needs to be rebuilt again, it's going to take a bit
 * --M86 (talk) 20:57, 8 December 2013 (EST)
 * No worries, just wanted to see if you knew about it. I got the dates from the source.
 * --DarkShadow (talk) 10:59, 9 December 2013 (EST)

A favor
I would like you to take a look at something on my core wiki at TechInfoDepot Core. It is a local wiki I make my changes there and use the extension "Push" to push my changes to http://www.techinfodepot.info which is hosted by shoutwiki. Would you like to create an account at TechInfoDepot Core or discuss here? --DarkShadow (talk) 21:15, 9 December 2013 (EST)
 * I apologize if I have offended you in anyway, that was not my intention.
 * --DarkShadow (talk) 23:32, 11 December 2013 (EST)
 * no offense taken
 * --M86 (talk) 20:47, 22 December 2013 (EST)

Link to chip pages
Is there a property for wi_chip that specifies a link to the chip page? For example, in the infobox of TP-LINK TL-WN721N, I would like the line "Chip 1: Atheros AR9271" to link to Atheros AR9271 which contains additional chip detail (datasheet, pinouts, etc shared among all AR9271-based products). Same goes for all other products using AR9271. Same goes for other chips, for example: Eventually each chip would have its own page with properties, and then products would only link to the chip properties instead of replicating all properties.
 * Ralink RT5572
 * Atheros AR9271
 * Atheros AR7010
 * Atheros AR2313
 * In the chip pages, can you add an infobox with chip properties? The RT5571 and AR9271 have most properties filled up for now.


 * Hm? No, all the 'ChipX' properties are currently split into 'Brand' and 'Model' properties - see, for example, the properties used by the WNDA3100v1.
 * .. but, that doesn't really matter, the infobox template will have access to the passed 'ChipX' parameters directly - #ifexist can be used to check if the page exists and it can then be linked
 * --M86 (talk) 17:25, 7 December 2013 (EST)


 * Link to Atheros AR9271 seems to work in ALFA Network AWUS036NHA infobox. But link to Atheros AR9331 doesn't seem to appear in infobox of TP-LINK TL-MR3020. Is this another caching issue? (tried refreshing without success).
 * --X64 (talk) 15:16, 21 December 2013 (EST)
 * It's not a caching issue, it's just unimplemented in the 'embedded system' templates at the moment
 * --M86 (talk) 20:47, 22 December 2013 (EST)


 * Another small bug report: in Cameo WLN-2229, the following are not linked to the chip page (the chip page exists - Atheros AR1311). Template hierarchy is too deep for me to find the correct template to fix :( :
 * ETH chip1: Atheros AR1311
 * Switch: Atheros AR1311

It should work for those fields now.
 * --M86 (talk) 01:43, 6 January 2014 (EST)

RAM
Hi, is it possible to have some simple RAM form? And connect it with existing information on Embeded systems and so on. Size, tyming, number of pins, data bus width, adress bus width. Number of raw, column and banks are needed. This will help to find replacement or upgrade for existing embeded systems.
 * --Fishor (talk) 09:40, 15 November 2013 (EST)
 * It would probably be best not to cram all of that info into the device entry pages itself - separate page(s) w/ chip specifications stored as triples would probably be preferable. If the data exists, it can be displayed along with everything else in the infobox.. and a query link or something could be added to find chips with similar / compatible specs.
 * --M86 (talk) 18:45, 15 November 2013 (EST)

Here is one example Hynix_HY57V281620ETP-H
 * --Fishor (talk) 03:01, 16 November 2013 (EST)
 * the general layout would probably be OK, but, it may be best to put multiple (similar / same family) chips on the same page
 * it would probably be best to shove package info, process tags, and the function summary / type tags (or whatever) into a general 'Chip' schema
 * so, something like


 * would be my idea of a layout w/ the sample chip you chose
 * --M86 (talk) 16:10, 17 November 2013 (EST)

Looks good. So probably in this case will be General = HY57V281620ETP, and variants or family = HY57V281620ETP-H. Or do you wont to include all "128Mb Synchronous DRAM based on 2M x 4Bank x16 I/O" with TSOPII-54?
 * --Fishor (talk) 09:15, 18 November 2013 (EST)
 * If there are not many significant differences between them, all of the HY57V281620E(L)T(P) chips could probably be lumped onto the same page
 * --M86 (talk) 16:59, 18 November 2013 (EST)

L - is low power; P - Lead free. Thay will fit to one page ;)
 * --Fishor (talk) 17:18, 18 November 2013 (EST)
 * Hmm... May be it make sense to have sort of differential tags? There is no need to add same information if there is only different Clock or not Leaded.--Fishor (talk) 05:02, 21 November 2013 (EST)
 * Most of the information could be fetched from a parent object, I suppose - but I'm not sure if that would be the best way to handle that
 * --M86 (talk) 17:09, 22 November 2013 (EST)

ICID
Do you know what this acronym stands for? --DarkShadow
 * --(talk) 17:33, 14 November 2013 (EST)
 * Industry Canada ID
 * --M86 (talk) 17:35, 14 November 2013 (EST)

EAN link to ebay
Hi, is it possible to provide EAN link to ebay? At least Europe ebay provide only EAN number.
 * Hmm.. looks like it is now working with ebay.com. Only with ebay.de, ebay.fr and so on.
 * --Fishor (talk) 13:56, 23 July 2013 (EDT)

right, it's hard linked to ebay.com at the moment. it could be localized, but it would require additional effort.
 * --M86 (talk) 14:01, 23 July 2013 (EDT)

Sort of SoC wifi usb adapter
Hi M86, there are many different chips for usb wifi adapters, which can be actaully called SoC. Thay have ROM, RAM, CPU, USB, UART and JTAG ports. Right now we need info about adapters with accesable UART. And i can provide some info too. What is the best way to do? Add this information to existing form, or create new form for this kind of devices?
 * --Fishor (talk) 04:38, 2 July 2013 (EDT)
 * Right.
 * .. hmm. I guess just adding a simple checkbox on the form would be good enough for the moment. Pinout and everything else can be stated on the free text on the page (much like it is for some routers).
 * --M86 (talk) 18:23, 2 July 2013 (EDT)

Image license
What license can I tag the pics that I mirror on my site techinfodepot.info? --DarkShadow (talk)
 * --12:31, 26 June 2013 (EDT) aka WifiShadow (talk)

How about Cc-by-sa-3.0? --DarkShadow (talk) 12:54, 26 June 2013 (EDT)


 * CC BY-NC-SA 3.0 would be preferred for most.. excepting any for which it would be non-applicable (public domain / re-hosted images / etc) and any with a different license declared (some images uploaded by other users).
 * --M86 (talk) 14:41, 26 June 2013 (EDT)

Firmware section
Hi, probably i needed to create separate talk. But it looks like you are the right person to ask. I would like to have Firmware field in WiFi form. For example many access points based on VxWorks. Many different firmware updates have same VxWorks version. Netgear_WG102 has 3 major firmware revisions (3.0; 4.0; 5.0) but all them are based on same VxWorks 5.4.2. It is really interesting from security perspective and for creation of alternative firmware. One more thing, this AP support 152bit WEP encryption. I think it is good to list such exotic things too.
 * --Fishor (talk) 05:30, 20 January 2013 (EST)
 * Yeah, the data should probably be collected and noted somewhere.. I don't know what the best method for doing that within the framework of SMW would be, though. Dumping all of the info in the main W_e_s template would not be the best solution..
 * At the moment, it can probably be safely dumped onto any device page.
 * Long term, a separate subpage for each device with firmware information may be desirable... it may be too much to jam it all on the main device page, but selective information from the subpage can be queried and displayed there if needed.
 * information that would probably be useful..

OS used + related information general firmware notes major changes from previous firmware, if available capabilities problems firmware size date of firmware release language + country of distribution device drivers used + versions programs used + versions interface screenshots default login credentials (indeed, currently in the main device page, but would probably be better to log on a per firmware basis [if any variance or different stock firmwares]) port scan dump known vulnerabilities packet dumps (wireless and non) - not currently viable without enabling general file uploads, which may not be desirable an actual copy of the firmware for download (same) link to firmware source, if available (+ mirrors) binwalk dump etc. etc. etc.
 * --M86 (talk) 15:15, 20 January 2013 (EST)

Ok, then i will just dump every thing i found on the device page. This will help to gather some experience and find some patterns. How about firmware binaries? Not all firmware seems to be easy to download. Some alternative repository will be good. --Fishor (talk) 07:01, 21 January 2013 (EST)

Couple of things
Kitty selection is not working. When you select all the cats and hit save it fails and loads another set of pic's. Tried several times just to make sure I was selecting the proper pic's.
 * --WifiShadow (talk) 08:35, 19 January 2013 (EST)
 * It appears that the Asirra implementation in ConfirmEdit is currently bugged to some extent (maybe only in newer MediaWiki versions). Installing Bachsau's latest build seems to have resolved it...
 * --M86 (talk) 17:00, 19 January 2013 (EST)

What modifications did you have to make to get large images to display without error? A specific example is
 * --WifiShadow (talk) 08:35, 19 January 2013 (EST)
 * wgMaxShellMemory is too low by default.. so Imagemagick will choke on larger files
 * Adding the following to LocalSettings.php should resolve the issue.

$wgMaxShellMemory = 262144; $wgMaxShellFileSize = 262144;
 * --M86 (talk) 17:00, 19 January 2013 (EST)
 * Hmmm, what if Imagemagick isn't being used? How easy is Imagemagick to install and get running? I am running XAMMP for windows. I have found a workaround, reducing the image size to 4000x???? seems to fix the issue. --WifiShadow (talk) 20:33, 19 January 2013 (EST)
 * Perhaps you need to tune $wgMaxImageArea (on MediaWiki.org) ?
 * --M86 (talk) 21:23, 19 January 2013 (EST)
 * Good show default is 50MB (setting is in bytes), I changed it to 75MB "$wgMaxImageArea = 78643200;" --WifiShadow (talk) 02:36, 20 January 2013 (EST)

SoCs with and without radio
Hi, you pointed on netgear Netgear WG102 and many other AR2313A devices, that AR2313A has build in radio. It has build in DAC/ADC units but no radio itself. May be we need some other description for it. It is confusing to have SoC with buildin and without radio on same line.
 * --Fishor (talk) 09:21, 13 January 2013 (EST)
 * .. if you're talking about the Atheros chipset page, Radio chips could probably simply be changed to Addl. RF chip (or something of the like) with pretty much the same meaning.. but I don't really understand if that is what you have a problem with.
 * --M86 (talk) 16:47, 14 January 2013 (EST)
 * .. some SoCs have build in RF some not. For example AR2313A has no RF; AR7130 has build in RF.
 * --Fishor (talk) 17:34, 15 January 2013 (EST)
 * I still do not get what point you are trying to get across.
 * AR2313 does indeed have no RF transceiver built-in.. but the MAC+BBP (+ DAC/ADC) is still integrated into the SoC. It is a WiSoC.
 * AR7130 is not a WiSoC, unless I am missing something. Wireless controllers used along with this chip will generally be connected via the external PCI bus.
 * --M86 (talk) 18:20, 15 January 2013 (EST)
 * The point is - i wont to learn, how embeded system work. This wiki is a realy big help (So, thanks to every one who doing this!). But i am confused about same name "WL1 chip1"... "WL1 chip2" for different things. Beside for some time i thoight - chip1 and chip2 have same funktions.
 * Now i see AR7130 is not WiSoC. How about AR9331? If i'm correct - AR9331 is a real WiSoC and AR2313 is partial.
 * --Fishor (talk) 02:41, 16 January 2013 (EST)
 * Current wiki convention...
 * WI chip1 = MAC or MAC/BBP or MAC/BBP/RF
 * WI chip2 = BB or RF
 * WI chip3 = RF
 * This doesn't work for all instances (mostly older non-integrated chipsets), but it works well enough for most. Stand alone front-end modules, power amplifiers, and everything else are not currently being recorded in any of the infoboxes (but I guess it would be nice to mention them in the page somewhere).
 * AR9331 is indeed a WiSoC. AR2313 is as well - it is just less integrated.
 * --M86 (talk) 12:12, 16 January 2013 (EST)
 * Thank you for explanation and for correction on Atheros page :)
 * --Fishor (talk) 12:32, 16 January 2013 (EST)

Expanding Scope
Hi, I tried to send an email via the OpenWRT forums but got no reply.

Could we polish and expand the scope of wikidevi to cover:
 * More structured information about firmware (versions, drivers, kernel, license)
 * Some cost and availability information (danger of going stale, but initial availability date and price at minimum; can use mediawiki as-of tags also)
 * Structured information about chipsets and processors (architecture, family, specific MPNs, markings, etc)
 * Some non-wireless devices (development boards like the beagleboard)
 * Add semantic forms to make reporting new devices easier

I'm happy to jump in and do this this myself, but don't want to step on any toes making large-scale changes.
 * --Bnewbold 18:30, 3 June 2012 (EDT)


 * Per structured information on firmware, I personally would think the wikis of the parent firmware project would be the best place for this information.. The status of the default firmware and bootloader would probably be of interest, however.


 * Cost and availability information would be OK, I guess.. echoing an earlier reply, flagging devices with their FCC ID entry date would probably suffice, though the MSRP would be a bit harder to ascertain.. The 'availability' property as it stands is currently useless.


 * I have no qualms with adding structured information about chipsets. I would presume this to include creation of a parent category (perhaps a CPU/SoC category and a 802dot11 chip category) and chipset pages (with a semantic query to aggregate devices using said chipsets) to be included in said category.


 * Non-wireless devices are covered (currently) by the (sparsely populated) 'Wired embedded system' category. Someone else decided to make that, I was just throwing everything in 'Wireless embedded system' despite non-wireless status.. though 'Wireless embedded system' also currently has some non-wireless devices in in (most notably the Ubiquiti Networks RouterStation and RouterStation Pro). Perhaps it would be best renamed to 'Embedded system, non-wireless' or something, since Ethernet may not be included in some of the boards that would be included in that category.


 * Enabling Semantic Forms would be nice.. but I haven't looked into it too much. SNPedia used to use it and I have personally always found it more useful to just copy and paste the template..
 * --M86 22:23, 3 June 2012 (EDT)

Semantic wiki field for support/not support by vendor still?
I think it would be useful to add another item to the templates that uses a semantic wiki field to allow people to query if a product is supported/not supported by the vendor still. I'm going through a list of about 100 adapters and many of them are no longer officially support by the manufacturer (end of life). It could be something like Supported:Yes,No,Unknown or Discontinued: Yes, No, Unknown. I'd be willing to add it to the 100+ pages I've been going through. What do you think?
 * --98.218.56.231 23:41, 28 March 2012 (EDT)


 * TBH, I don't see that as having much utility (and likely as a pain to manually curate). Most products on here are EoL without support from their respective vendors (assuming they still exist) and those that are not will soon be.. Something like an approximate date of product release (FCC ID filing dates being the primary source) might be useful to give a ballpark estimate of support, however..
 * --M86 00:12, 29 March 2012 (EDT)

Authentication for Saving
When a page is saved on your wiki cats have to be picked out of a lineup to prevent spamming. How do I go about setting that up on my wiki? If need be I can let you create an account on my wiki and upgrade your user status if you'd like to set it up or if it can even be done that way.
 * --WifiShadow 12:18, 12 March 2012 (EDT)


 * The kitten auth system is Asirra. There is an Asirra extension for MediaWiki which will integrate it into the wiki. Setup and configuration should be trivial, just follow the instructions on the Asirra page and the ConfirmEdit page.
 * --M86 15:13, 12 March 2012 (EDT)

InfoDepot
I am Admin of that site on Wikia, I am no longer keeping that site up to date. I have copied all my information and am now serving on http://www.techinfodepot.info


 * Ye, I know. Would you like the links currently pointing to InfoDepot on Wikia to point to techinfodepot.info?
 * --M86 19:47, 6 March 2012 (EST)


 * Yes that would be cool.
 * --WifiShadow 06:47, 7 March 2012 (EST)


 * Love your Setup
 * --WifiShadow 19:45, 11 January 2012 (EST)