| The Following User Says Thank You to pullrequest For This Useful Post: | ||
|
|
2017-10-17
, 17:59
|
|
Posts: 248 |
Thanked: 1,142 times |
Joined on Dec 2014
@ Earth
|
#272
|
planning to do a rebuild in a couple of days, I notice some people want CONFIG_MODULES enabled, BTRFS and TRIM support. Think I'll bundle them in, anything else people fancy?
| The Following User Says Thank You to DrYak For This Useful Post: | ||
|
|
2017-10-17
, 18:08
|
|
Posts: 367 |
Thanked: 1,442 times |
Joined on Feb 2015
|
#273
|
Thanks for the reference but this is the Near Field Communication device (NFC).
And I would like to have kernel support for the Network File System (NFS).
|
|
2017-10-18
, 10:43
|
|
Posts: 292 |
Thanked: 294 times |
Joined on Jan 2012
@ Milan, Italy
|
#275
|
| The Following 2 Users Say Thank You to Watchmaker For This Useful Post: | ||
|
|
2017-10-18
, 17:08
|
|
Posts: 102 |
Thanked: 187 times |
Joined on Jan 2010
|
#276
|
@mikecomputing, would be great to have active and contributing members in the community. I don't think we are in position where we should just sit and wait for SFOS to get better
...
No idea whether its allowed, but its a fair question. Its just insane that we have to use proprietary bits for text prediction. When (if) I get off the navigation software development, I would be happy to help anyone to get this piece of SFOS replaced with some open-sourced solution. Just would prefer to finish what I started before first. Any takers for developing text prediction for SFOS so we can drop XT9?
So for me the OKBoard is a nice piece of software and a good foundation for same or next word predictions with the swiping as icing on top of the cake. I helped promoting OKBoard by providing the Swedish language models very early on and helped others build resources for their favourite languages. OKBoard ties in nicely with the current maliit keyboard infra. As a language technologist I already back in the 90s did text prediction. Most lessons learned are that we should avoid special solutions but build something that tie in or adds to existing open solutions. In the case with xt9 we know the infra is not too restricted, so we could replace it fully with good enough API's for our free solution.
| The Following 6 Users Say Thank You to ljo For This Useful Post: | ||
|
|
2017-10-28
, 21:21
|
|
Posts: 1,746 |
Thanked: 1,832 times |
Joined on Dec 2010
|
#277
|
net/built-in.o: In function `qtaguid_mt':
ipc_router_security.c.text+0x692ac): undefined reference to `xt_socket_put_sk'
ipc_router_security.c.text+0x69350): undefined reference to `xt_socket_get6_sk'
ipc_router_security.c.text+0x69360): undefined reference to `xt_socket_get4_sk'
ipc_router_security.c.text+0x693bc): undefined reference to `xt_socket_put_sk'
net/built-in.o: In function `tcp_nuke_addr':
ipc_router_security.c.text+0x7fdd8): undefined reference to `in6addr_any'
ipc_router_security.c.text+0x7fde8): undefined reference to `in6addr_any'
ipc_router_security.c.text+0x7ff40): undefined reference to `rt6_lookup'
make[2]: *** [vmlinux] Error 1
make[1]: *** [sub-make] Error 2
make[1]: Leaving directory `/home/martin/hadk/kernel/sony/msm'
make: *** [TARGET_KERNEL_BINARIES] Error 2
| The Following User Says Thank You to m4r0v3r For This Useful Post: | ||
|
|
2017-10-29
, 08:25
|
|
Posts: 248 |
Thanked: 1,142 times |
Joined on Dec 2014
@ Earth
|
#278
|
enabling modules causes this error
make[1]: Leaving directory `/home/martin/hadk/kernel/sony/msm'
| The Following User Says Thank You to DrYak For This Useful Post: | ||
|
|
2017-10-29
, 09:04
|
|
Posts: 1,746 |
Thanked: 1,832 times |
Joined on Dec 2010
|
#279
|
| The Following User Says Thank You to m4r0v3r For This Useful Post: | ||
And I would like to have kernel support for the Network File System (NFS).